JISC DataPool Project

Computer Applications and Quantitative Methods in Archaeology (CAA) 2012 conference, hosted by the Archaeological Computing Research Group in the Faculty of Humanities at the University of Southampton on 26-30 March 2012

How do you give a conference presentation when your laptop with the presentation on it dies 1 hour before the presentation? You tweet it.

Graeme Earl is co-investigator with the DataPool Project. He is also a senior lecturer in archaeology at the University of Southampton and organiser of the Computer Applications and Quantitative Methods in Archaeology 2012 (CAA2012) conference being held in Southampton this week (26-30 March). So this is an especially busy time for Graeme, yet he still wanted to give a presentation on DataPool to his own research community.

Why choose the novel means of presenting via Twitter? Graeme explains: “I decided at lunchtime that I would give the paper via twitter, and upload slides as an accompaniment. An hour before the paper my laptop died catastrophically and, irony of ironies, my presentation materials were on my laptop rather than on a network location. So I assembled the presentation as links in 30 minutes and then delivered it.”

In case Graeme hasn’t time to blog his presentation as well, we’ll do it for him. Twitter is intended to be an immediate service so retrieval can get harder over time. You may be able to find the original tweets by searching for Graeme’s username or for the hashtags he used. To avoid repetition these have been removed from the tweets and are copied immediately below. There is also some brief annotation of links between tweets to assist readers. Otherwise, tweets are as Graeme’s originals. For reference, the presentation was given around 5 pm on Wednesday 28th March.

@GraemeEarl #caasoton #datapool #jisc

> Starting my tweeted paper on #datapool now #caasoton

> http://t.co/EX7ZgsGj Managing Research Data

Report on Developing Institutional Research Data Management Policies, a JISC Managing Research Data (MRD) Programme meeting held in Leeds on 12-13 March.

> http://t.co/fed0BzoE

This blog.

> http://t.co/Rkff1pVq Research data management infrastructure

Research data management infrastructure projects (RDMI), Web page on the first phase of the JISC MRD programme.

> http://t.co/zMva6Lx5 IDMB

JISC project page for IDMB: Institutional data management blueprint, predecessor project to DataPool.

> Creating a system – sharepoint, repository, metadata http://t.co/7TydrHQJ

DataPool poster paper, on Graeme’s Slideshare account.

> Rolling out a policy – ratified, embedded, implemented

> Producing examples – discipline, re-use case studies, domains e.g. imaging

> Developing skills – training staff and students; ‘help desk’

> Sharepoint infrastructure provides data access and collaboration

> University deep storage repository + connection to others e.g. via SWORD2

> ADS SWORD ARM project http://t.co/VzGKCGkU

JISC project page for SWORD-ARM: SWORD & Archaeological Research data Management.

> ADS page for SWORD ARM facilitating deposit from outside to ADS repository http://t.co/TEJ7HSz1

SWORD-ARM blog.

> Middle layer of metadata management – initially project/sub-project/item hierarchy

> Publication – push to and pull from external repositories e.g. ADS; policy implications for this?

> Provide external access to cache and deep storage versions

> Demonstration repository; trialling with https://t.co/uMr69v5x

Portus Project, Digital Humanities, University of Southampton.

> Presented at Soton Research and Enterprise Advisory Group (REAG) http://t.co/17GepTLs

A project for the research life cycle? DataPool blog post, 8 March 2012.

> Ratification by Soton senate; included user guides also clarify uncertainties

> Defining core focus areas e.g. USRG Imaging http://t.co/82KfVJrd

Computationally Intensive Imaging, University Strategic Research Groups (USRGs), University of Southampton.

> Building network of experts and interested people http://t.co/TvnF4p0r

Data system, policy, training: putting people first, DataPool blog post, December 8th, 2011.

> Defining internal dissemination mechanisms e.g. USRG DE https://t.co/TxoXWuXY

Digital Economy USRG, University of Southampton.

> data management plans presented to other JISC projects http://t.co/Kth6o8EL

Data management plans (DMPs): the day has arrived, DataPool blog post, 22 March 2012.

> Details of meeting disciplinary challenges in research data management planning workshop http://t.co/ELd7hEvg

Agenda for JISC workshop on Meeting (Disciplinary) Challenges in Research Data Management Planning held in London on 23 March.

> Finished. Taking questions.

> @PatHadley thankfully I had a helper to advance them for me!

That’s it: presented, tweeted, now blogged.

Changed Days at Paddington Basin, Colin Smith, Geograph Project

Updated 28 March 2012

The day has arrived for data management plans (DMPs). It’s tomorrow (Friday 23rd March 2012) when Research Data Management Planning Projects from the JISCMRD (2011-13) programme convene a workshop in Paddington, London, to present their findings and results. But has the day for DMPs arrived in a bigger sense? Are DMPs pivotal to research data management? I suspect so, and at the meeting I will be looking for evidence to support the assertion, or not.

DMPs are the link between the conception and proposal of research projects, and the later production of data from those projects. These plans can be extensive and demanding to produce, but as a result the information they contain should be invaluable to data repositories. This is not the type of information the researcher is likely to provide again at the point of depositing data in an institutional data repository.

DMPs represent carefully planned information on the project and predict the existence of data, in some cases precisely. This creates a link with emerging research data policy, which requires an open record of data produced in the course of funded research and the effective management and storage of that data. DMPs have a role to play in monitoring and ensuring the completeness of the records.

This approach raises a series of questions about DMPs. What is the scope of a DMP, and who defines this? This is most likely to be the research funder, but might be institutions in other, non-funded cases. In what form will the DMP be completed? Presumably online. Where will online DMPs be hosted? The Digital Curation Centre, not a research funder, hosts the DMP Online tool. Should institutions create and/or host DMP tools? To what extent will it be possible to (pre-) populate data repository records from DMPs? How comfortable are funders, institutions and researchers about sharing and publishing information from DMPs? The answers will involve specifying where DMPs fit the researcher’s workflow, ensuring there is no duplication of effort, and allowing DMPs to be driven by the needs of research and researchers, not by systems requirements or other special pleading.

These are some of the issues that will be in my mind when listening to the DMP project presentations tomorrow, and which I shall report on afterwards.

Update. Following the JISC DMP meeting in Paddington, Meeting (Disciplinary) Challenges in Research Data Management Planning Workshop, and further feedback from key presenters, some of the questions I posed can begin to be answered. For me the key presentations in this context were by Kerry Miller and Adrian Richardson from DCC, who updated the meeting on future plans for the DMP Online tool, and from David Shotton, a zoology researcher at Oxford University who has been compiling a more researcher-friendly set of 20 DMP questions.

First, we were shown how DMP Online v3.0 now includes selectable templates for e.g. different funding council requirements, so we can see how customisation of DMP input forms is beginning to take shape. We can also see from the plans for DMP Online that one possibility being considered for the tool is Ability to host locally within institutions. This was my choice in the selection exercise, but it appears others did not rank this feature so highly. My recollection is this group exercise was somewhat curtailed, and the tied rankings for many features suggest the returns were not high, so I hope the development team will not feel bound to the ranking of these results.

Now to David Shotton’s analysis of a short, customised set of DMP questions. If we are to host locally and customise DMP tools, we need to be careful we do not get away from the core requirements of the forms, which are not simply to suit individuals or institutions. They still have to be grounded in formal funder and research requirements. So having framed his 20 DMP questions, David looked into comparing and aligning his questions with known sets of DMP questions, including from DMP Online and the US equivalent DMP Tool, and others. To make this alignment David created a downloadable spreadsheet containing the aligned DMP questions, which can be found in a link towards the end of the blog post. An analysis of this comparison is provided in a follow-up post, also linked.

That’s enough for this update. It’s time to look at David Shotton’s analysis and at the plans for DMP Online in more detail. I expect to return to this. I can’t answer yet my latter questions on whether researchers and funders will be happy with the approaches being considered here, nor how soon this work might come to fruition by integrating DMP tools in data repository-based research workflow. Even to suggest this phrase leaves me accused of over-egging this particular pudding. What I can say is that answers to my first questions, on customisation and hosting, have begun to be revealed and they are highly encouraging.

How do we view a project like DataPool?  What are we hoping to achieve?  These are important questions that need to be kept in mind throughout the life of the project.  It can be easy to become focused on specific tasks.  Projects can be seen as simply ”a project” with a fullstop and an end, but DataPool is more than “just” a project testing ideas and systems.  It will do that, but we hope that it will do much more.  DataPool is about beginning the process of embedding the management of research data into the infrastructure and culture of our institution.  DataPool is here to make a difference and to make it throughout the research life cycle, from proposal to storing and sharing.

Bedrock

The bedrock underpinning the project will be a Research Data Management Policy for the University.  This will be key to all the other work and will inform the related guidance and training requirements.  Its development is being seen as an iterative process with views of the academic community initially being gathered through designated “data” contacts within the Faculties.  The policy will be valuable in informing data management processes in the University, influence plans where required by funders and will be a significant benefit arising from the DataPool project.  We would hope by the end of the project to see an increased number of references to the policy within research proposals, resulting over time in an increased number of datasets held securely and in a location that makes them available for re-use.

Infrastructure

The increased focus on research data, its management, storage and sharing requires that the systems offered within the University of Southampton are adapted and developed so that they can meet this need.  DataPool will be of benefit to this process.  DataPool will work to inform the decisions concerning the technical infrastructure of the institution to provide a simple deposit system that will also facilitate sharing at the appropriate time and under approved conditions.  This will be geared towards the individual researcher, influenced by case studies and discipline exemplars, with the aim of seeing how best it can support the research data workflow and capture metadata from existing University systems.  By the end of the project we would expect to have enhanced the storage and deposit options available, and seen an improved uptake of them.

Support

The start of the data life cycle is long before the creation of any data and really begins with the research proposal.  We plan to draw together a network of services that will support the researcher from proposal to deposit.  This will draw on existing services and expertise, both internal, such as our Research and Innovation Service, Doctoral Training Centres, Library, and external ones, such as the Digital Curation Centre.  We aim to create: guidance sheets; training materials; and to offer workshops and a web site. These will enhance the support that academic, professional and support staff can provide, whether for writing plans or advice on versioning through to different levels and types of metadata.  We would see the establishment of a central web site as an important step in this area.  The creation of this support will be a direct benefit arising from the Datapool project.

There seemed to be general surprise following the revelation that Damien Hirst does not always ‘make’ his own works of art. Instead he leaves production to assistants based on his ideas and designs. In effect, he architects his art. Similarly, high profile architects like Norman Foster or Zaha Hadid are no less creative forces if they are not also builders.

In the rather different world of managing research data (MRD) we need systems to manage these data, but given the range of different types of data and emerging requirements of data producers, their institutions and users, we should be careful about simply adopting existing systems or even systems designs. The options are potentially wide, and complex. Instead of the systems engineer, the stage we are at needs the systems architect to take a high-level view of all the requirements to produce an elegant solution, fit for purpose and designed for the environment in which it is to be placed.

So I was interested to see the architecture for a research data repository at the University of Bristol illustrated by the JISC data.bris project. The accompanying description starts with front-ends and storage architectures and on the way refers to various technologies. The key feature, however, seems to be the recognition that this service must integrate with existing institutional information systems – not a unique view perhaps among current JISC projects, but one taken into account in the high-level architecture at the outset rather than as an afterthought.

Another of our companion JISC MRD projects, DataFlow at Oxford University, is developing a data deposit architecture that attracted my attention at the MRD programme launch meeting in Nottingham in December last year. This features a two-stage approach – DataStage and DataBank – that recognise different motivations for data deposit by researchers: 1, for storage and management (mimicking the popular Dropbox approach) prior to 2, data publication and access. The first is driven by researchers themselves, while the second may be more often driven by formal requirements by funders, institutions and policies. Broadly, these stages might offer a simple deposit interface and a more formally structured metadata collection interface, respectively (although I wait to see whether this is what DataFlow provides). The point about this approach is that it supports, and links, both motivations for data deposit.

What does DataPool offer in terms of a data system architecture? At the same Nottingham meeting the project presented a poster (pdf) including a diagram of a proposed system architecture. For those that saw it this graphic may have caught the eye for the splash of colour it brought to the poster, but the viewing context was not ideal for detailed information. It is worth reproducing that illustration here with some reflection on what it might offer to the general architectural principles we need to establish for research data systems.

Adapting the Southampton Microsoft Sharepoint 2010 system for data deposit

This diagram was produced by Peter Hancock, director of iSolutions, the University of Southampton’s ICT professional services department. Continuing development of this data architecture will remain an iSolutions responsibility in parallel with and beyond the DataPool Project. Where DataPool comes in is to seek to connect the data system approach with other institutional interests, notably researchers and users, through case studies and faculty contacts; training, through staff and graduate training centres; and policy, through the university’s research advisory and decision-making groups.

What follows are some thoughts on this architecture. First, as with DataFlow, this appears to be a two-stage architecture, in this case indicated as ‘Sharepoint’ and ‘Dropbox type infrastructure’. Actually, it would be hard to compare this too closely with DataFlow, or even Dropbox, without some illustration of the respective deposit interfaces, and that is for another post.

This figure omits to connect other deposit interfaces, which could be EPrints or SWORD for example, with the University Data Repository and storage service. Such interfaces might be produced by DataPool or others, rather than by iSolutions, but these will still need access to the underlying university data infrastructure.

Second, there are two access routes for users, which can broadly be defined as internal and external to the institution. As this is a service-oriented architecture this is inevitable and presupposes a privileged view for internal users. Whether this privilege extends beyond their own work is under discussion.

Finally, deposit is not restricted to the institution’s repository but allows data to be moved and copied between institutional and external disciplinary or subject-based data repositories. This might be accomplished via a service such as SWORD. Research data policies promote such options, providing chosen data storage services are reputable and appropriate, rather than specifying particular data repositories, and many researchers wish to exercise such choice.

All institutional research data services will need to make provision for extensive and expanding data storage. This is not elaborated in the figure, and strategy, infrastructure and costs for this continue to be discussed at a high level.

The point of an architecture is that it becomes a detailed plan for building, or in this case implementing a research data system. Prior to that, as a high level abstraction it serves as a platform for input for all interested stakeholders, from all perspectives. For DataPool those perspectives span the whole of the University of Southampton, and to capture those we have ensured we shall be working across faculties, with the faculty contacts, and with data producers through disciplinary exemplars and case studies. Ultimately, to make progress this has to be an iterative process of development and feedback, but central to this is the development of the architecture because that is what should reach out to most people.

At this conceptual level an institutional data management architecture will raise many questions. We may or may not need Sharepoint, EPrints, DSpace and other information systems solutions; what we need are systems to fit the architectural vision.

Institutional data policy is necessary as one of the drivers of changing practices towards research data across the institution. The role of data policy generally, according to Neylon, is to drive data availability, data management, and data archiving while stressing the importance of data as a core output of public research.

In our first post we identified DataPool’s three-pronged approach – system, policy, training – that we hope will enable us to develop and support a rich collection of research data emerging from the University of Southampton. Here we report on how the proposed research data policy is shaping at Southampton, and on progress piloting it through the research and senior management channels towards adoption.

Where we stand now with the policy at Southampton is it was recently given a final-stage presentation to the university’s Research and Enterprise Advisory Group (REAG), which directed the policy to the University Executive Group (UEG). Ultimately, UEG can forward it to the university’s highest policy-making body, the Senate, perhaps by March 2012 if it goes well.

This rate of progress is due in part to the work of our predecessor Institutional Data Management Blueprint project, but credit is also due to the sterling work of Wendy White and Mark Brown at the head of the DataPool Project in piloting the draft policy through the advisory group and policy-making networks. Wendy and Mark are veterans of the university’s Open Access Policy, so they know their way around the networks of influence concerning the development of institutional repositories.

The policy includes the policy document supported by a series of user guides to smooth implementation. It would be premature to describe the specifics of the policy here, although broadly it covers a researcher’s responsibilities, IPR, storage, retention, disposal and access, as well as setting out contextual issues such as purpose, objectives, and definitions. My viewpoint on reading the draft policy is to anticipate how a researcher might respond to it in terms of clarity of actions, options and consequences. In this respect it is noticeable how much the policy has improved through review and iterations. Admittedly it may not attract the same level of excited publicity as, say, an open data policy, but the scope is wider and the purpose more pragmatic.

We do not expect the policy to be without issues when it comes to implementation, clearly, for an initiative of this scale, but the policy will give the DataPool Project the basis to investigate and resolve the issues, in terms of actions and answers. On current schedule, there should be a year for the project to work with this.

There is little prior art on institutional data policy, and one of the reasons JISC has funded DataPool is not just to help produce a data policy, but to inform other institutions on implementation. Logged on the DCC page of UK Institutional data policies are currently just four examples, one of which is a ‘commitment’ rather than a policy, while others are in the early stages of implementation. Policy implementation, monitoring and ability to adapt are the real testing ground for this latest phase of research data management projects.

More, and somewhat better established, data policies can be found among the UK’s research funders, again as logged by DCC. These policies can be seen as context rather than competition for institutional data policies. One of the reasons managers of institutions might commit to research data policy are the requirements on their researchers that are embedded in the funder policies. For the institutions there is a need to support their researchers in complying with the policies, for no doubt there will in future be implications for research assessment processes. There is also the incentive of competition between institutions, and the scent of a leading edge in exploiting innovation driven by the profound changes in digital research data management. As Neylon says: “In the longer term, those who adopt more effective and efficient approaches will simply out compete those who do not or can not.” We will look in more detail at the funder policies and their implications for institutions in a later post.

One of the points of contention in emerging data policy is to define the term ‘research data’. How can policy on this be effectively implemented unless everyone has the same understanding? This may be a semantic argument, but it must also be rooted in current practice by researchers, and also in how that practice is already being shaped by current policy, notably from the research funders. My simplistic take here is that researchers are finding their own preferred approaches to storing and managing early-stage research data, that is, data some way from publication. We might call this the Dropbox approach. Meanwhile funder policy, on the other hand, tends to apply more to data that underpins publication, that is, is concerned with the quality and reproducibility of results, the bedrock of scientific testability. If simple and unrepresentative, this view on the different motivations and practices for capturing both early and late-stage research data nevertheless seems to mirror the framework of our companion JISC DataFlow Project at the University of Oxford, as represented in its DataStage (a secure personalized ‘local’ file management environment for use at the research group level) and DataBank (an institutional-level research data repository allowing researchers to store, reference, manage and discover datasets) processes, respectively.

Seeing the Southampton policy develop through engagement with research, policy and legal experts on advisory groups it is easy to anticipate this prospectively as a worthy policy exemplar for research data. It won’t be the last institutional research data management policy:

> @simonhodson99 By March 2013 all these #jiscmrd projects will develop research data management policies for their institutions http://t.co/gqzYf4pC #idcc11, 6 December 2011

Timing is key, and our aim is to bring forward policy ratification early in 2012 rather than by March 2013, the project end. It’s important to allow enough time to test the policy in practice. Given the scope of its intended coverage and the range of open questions posed by research data, it is possible the policy might contain unexpected holes or omissions that could limit uptake by both willing and unwilling researchers. Even when adopted – perhaps even more so when adopted – we have to be proactive and vigilant in monitoring how researchers respond to the institutional research data policy.

To support research data management across a large multi-disciplinary institution such as the University of Southampton you need a collection, storage and archiving system, right? Yes, but you need more than that. The proposal for the DataPool Project reveals that it will tackle three distinct developments:

• Research Data Management System Implementation
• Research Data Management Policy Ratification and Implementation
• Integrated Training, Guidance and Support for Researchers

So in addition to a system you need an institutional policy setting out requirements for participation by members of the institution, and training to help them do what the policy specifies using the system provided. We will return to these three developments often in this blog as the project builds, and the next posts will set out the details of where we start for each of these developments.

But there is another crucial element, and the clues are becoming clearer – that is, people. As one of the joint project managers for the DataPool Project, with my colleague Dorothy Byatt, the brief in the project proposal contains no magic bullet that will solve the challenge of rolling out digital data management to members and all disciplines across an institution, but it begins to set out a network of colleagues to help us achieve the goal.

Since we began the project Wendy White, co-investigator from the university library, has been extending this network beyond the co-investigators named in the proposal to encompass data contacts for all eight major faculties across the university, and leaders for a series of disciplinary case studies involving different data types produced by postgraduate and undergraduate students as well as researchers. We look forward to introducing data contacts and case study leaders as we report their work here.

We will, however, introduce our team of co-investigators now because they have shaped both the proposal and the prior project, the Institutional Data Management Blueprint (IDMB), that led to where we begin with DataPool. They are:

Mark Brown (Principal Investigator), Les Carr (computer science), Simon Cox (engineering sciences), Graeme Earl (archaeology), Jeremy Frey (chemistry) and Peter Hancock (iSolutions).

We hope they will have the opportunity during the project to introduce themselves as co-contributors to this blog.