iridium – JISC MRD02 monthly updates to January ’13

Progress to date

Workpackage 0 (Project Management)

  • 4th Steering Group meeting took take place on 08 January 2013, with two further planned for April and June 2013

Workpackage 1 (Requirements)

  • activities completed

Workpackage 2 (Policy)

Workpackage 3/4/5 (Tools, Systems, & Implementation)

  • Research Data Catalogue (RDC) user testing data loaded
  • DCC DMP Online tool used to host draft iridium institution-specific post-award DMP template
  • local CKAN test system established
  • e-Science Central Shibboleth authentication added, with SWORD protocol functionality being investigated

Workpackage 6 (Human Support)

  • additional good practice guidance content and revised draft policy principles added to developing RDM support website
  • meetings with Netskills on 09 Jan and 13 Feb 2013 to outlined RDM workshop and online training requirements
  • documentation for RDM tools authored
  • productive meeting with Staff Development Unit on 14 February 2013

Workpackage 8 (Evaluation)

  • draft RDM policy principles for available for open consultation from institutional website
  • testing fitness for purpose of identified RDM tools underway (see https://iridiummrd.wordpress.com/?s=tools+evaluation)
  • RDC minimal addition metadata entry testing and user acceptance will take place from February 2013, with 12 PIs invited to record data location (representing 39 research projects and 474 publications)
  • iridium support team have evaluated project RDMP template implementation within DMP Online system, to be followed by research funding support staff and researchers

Workpackage 9 (Dissemination)

  • Niall O’Loughlin (RES) gave a talk to research office representatives from Brunswick Group on 25 January 2013 on ‘Open Research Data’.

Activities in the last months

  • Dr Ben Allen and Dr Simon Kometa registered to attend ‘CKAN for RDM’ on 18 February 2013
  • Paul Haldane registered to attend ‘RDM Storage Workshop’ on 25 February 2013
  • Niall O’Loughlin registered to attend ‘Research data in the Visual Arts’ event on 06 March 2013

Risks & issues

Risk/issues likely to present in the coming 3 months are:

  • project still needs to be very clear that the iridium project is not about data storage space provision
  • managing researchers’ expectations about provision of RDM tools
  • REF 2014 will be a major priority for researchers and institution in coming months

Milestones & challenges

In the coming 3 months, identified milestones are:

  • project outputs (policy, tools and training) aligned into pilot infrastructure
  • pilot infrastructure evaluated against research projects’ needs
  • monitoring institutional IT re-structuring for embedding of project outputs
  • promoting uptake of pilot infrastructure and outputs
  • business case authoring
Advertisements

iridium JISC MRD02 – monthly updates to November ’12

Progress to date

Workpackage 0 (Project Management)

  • draft proposal for extension of project submitted
  • full-team meeting took place on 12 November 2012 to review project against JISC Progress Meeting RDM ‘components’

Workpackage 1 (Requirements)

  • requirements gathering outputs disseminated locally and externally to JISC MRD Programme
  • resultant project actions dissemination locally to stakeholders through Registrar’s regular update to Heads of Departments
  • anonymised requirements data shared with local projects and initiatives (Computing Science data security Choice Modelling, Digital Campus Initiative Infrastructure Discovery and ISS Information Security projects)

Workpackage 2 (Policy)

  • working group met on 06 September and 27 September 2012
  • policy principles and Code of Good Practice have been revised and are in a mature draft form
  • briefing of senior project advocates is planned ahead of tabling of draft policy document at URC
  • permission will be requested from URC for draft policy principles to be published on project website for open consultation

Workpackage 3/4/5 (tools, systems, & implementation)

  • research data catalogue will be tested with subset of Changing Age researchers
  • draft Newcastle-specific post-award DMP template will be tested within DCC DMP Online system from Decemebr 2012
  • SWORD2 protocol investigations blogged
  • CKAN platform to be tested

Workpackage 6 (Human support)

  • RDM support materials writing sessions continued on 08 and 18 October 2012
  • RDM support website has being populated with FAQ, draft policy principles and good practice guidance content
  • documentation of selected RDM-specific tools continuing
  • Dr Simon Kometa (ISS) attended JISC ‘Research Data Management Training’ workshop on 26 October 2012

Workpackage 8 (Evaluation)

  • draft policy principles reviewed in light of comments received from stakeholder to date
  • evaluation to date reported internally on tools (i.e. e-Science Central and DMP Online)
  • Lindsay Wood attended JISC benefits meeting in Bristol 29-30 November 2012

Workpackage 9 (Dissemination)

  • newsletter-style project update disseminated on 05 October 2012
  • project disseminated at JISC Progress Meeting on 24-25 October 2012
  • Niall O’Loughlin (RES) gave a talk to AFRD Research Committee on 09 November 2012

Activities in the last months

  • EPSRC-funded FRICCTT report published that referenced JISC iridium project
  • local EPSRC-funded Cyber Security project awarded that referenced JISC iridium project requirements gathering data in case for support
  • Lindsay Wood attend JISC IRIOS-2 RIM meeting in Newcastle on 21 September 2012
  • Suzanne Hardy (MEDEV) attended the DataCite citing sensitive data workshop on 29 October 2012 at the British Library
  • Dr Ben Allen (ISS) attended RDMF9 workshop on 14-15 November 2012 in Cambridge

Risks & issues

Risk/issues likely to present in the coming 3 months are:

  • project still needs to be very clear that the iridium project is not about data storage space provision
  • managing researchers’ expectations about provision of RDM tools
  • degree of policy revisions post-URC, that might be required, is unknown
  • maintaining good communication links with the URC during project team staffing changes
  • REF 2014 will be a major priority for researchers and institution in coming months

Milestones & challenges

In the coming 3 months, identified milestones are:

  • draft policy approved by URC and then by Executive Board
  • project outputs (policy, tools and training) aligned into pilot infrastructure
  • pilot infrastructure evaluated against research projects’ needs
  • monitoring institutional IT re-structuring for embedding of project outputs

SWORD v2 – From clueless to claymore

What follows is a summary of my steps along the path of investigating what the sword technology is, through to being able to actually start to code something useful; I should probably point out that the beginning of this post can be consumed by less technical persons as a quick overview, but the later section assumes that you…

  • Have some knowledge of coding java
  • Have worked with java server containers (e.g. tomcat) before
  • Can place the libraries in an IDE like netbeans/eclipse to do “something” with them

(Since my investigations centered around sword in conjunction with Sakai and e-science central my language of choice therefore is Java).

I should also declare that I still don’t fully understand all of the implementation but this should help you along your way if you’re just starting out!


Taking the Sword course

My first port of call was the SWORD website itself, which will point you to some useful videos and slides to give you insight into what the technology is and what it can be used for. In short, this is what the “Sword Course” will teach you…

An Introduction To SWORD (Video/Slides)

What it is:

The “Simple Webservice Offering Repository Deposit” technology (or SWORD for short) intentionally only deals with how to get data into a repository, nothing else, and is complementary to something like dublin core used to describe stuff in a repository; it also does not deal with packaging, metadata, authentication or authorisation

Existing implementations can be found in:

DSpace
Eprints
Fedora
Intralibrary
Zentity

SWORD Use Cases (Video/Slides)

Use cases sword is trying to enable:

  • Deposit from a desktop machine
  • Deposit to multiple repositories (For example to allow depositing once and ending up in an institution’s repository, funder’s repository and a subject specific repository)
  • Deposit from a piece of lab equipment (non-human depositing data)
  • Deposit from one repository to another (For example Institutional repository to National repository which may have differing visibility of the data…. Dark and light repositories, dark = can’t be seen private repositories, light = can be seen public repository)
  • Deposit from external publisher/publishing system to long term storage (For example from OJS to your own institution’s repository)

How SWORD Works (Video/Slides)

  • SWORD is in the form of an “XML REST webservice to put things in a repository”
  • It has built on the resource creation aspects of the ATOM Pub standard which is for publishing content to the web
  • SWORD is an extension, or “profile”, of the ATOM Pub spec and existing ATOM Pub clients can be made to work if the relevant extensions are added
  • SWORD version 2 now includes full CRUD

When you use a sword client, this is basically what happens…

  • The client asks a repository to describe itself
  • The server returns a “Service document” to describe what you can do with the repository and how to do that. The service document is typically hidden by Basic Auth Authentication (AM: I think this is crying out for an OAuth implementation!) but once authenticated the web service will customise the service document to what you are allowed to / should do with the system. The server can also describe what data formats you want to accept, where it will go and how long you will store it etc… this is your “collection policy”
  • The client then uses the service description to format your data and then deposit it

What sword adds to ATOM Pub:

  • Accept Packaging – Tells the client what types of data the server accepts
  • Mediated Deposit – Allows you to deposit “as” / “on behalf of” someone else, a repository can say whether it allows this or not
  • Developer features – You can state that you want verbose output to say what happened (v1.3 featured a dry run feature called “no-op” that does not actually deposit or do anything. NOTE: this does not appear to be in v2 anymore)
  • Nested Service document – Where there may be many repositories for the service, the top level document provides links to sub documents, instead of repeating the same or similar definitions in one enormous file.

SWORD clients (Video/Slides)

There are generally three sorts of client:

  • Machine to machine – for very specific automated deposits (lab equipment)
  • General – human would use, talks to any repository
  • Specific – for depositing certain data into certain repositories in a given way that has an extra context of a general client, i.e. depositing specific journals, depositing data for a particular project

Interesting possibilities for deposit scenarios:

Writing something useful

My next stop on the journey through sword looked at actual code, how it’s laid out and what you need to do in order to start doing something useful.

As mentioned previously, I have been basing my investigations around the Java client and server libraries but I’d strongly recommend you also get a good grounding in the workings of ATOM Pub (HTML Version) and the Sword Profile specifications themselves. If you’ve ever read specification documents before you’ll know they can make quite dry reading, however, since ATOM Pub and sword are relatively straight forward technologies and the specs only reach into 30-50 odd pages it’s really worth a browse through.

How SWORD works in java

Firstly, it’s probably best to understand a few basic concepts you will need to deal with, the main outputted concepts/objects are:

  • IRI‘s – unique identifiers to a resource
  • Entry – A deposit, has IRI’s/metadata
  • Media – An entry for media (word docs/pdfs/images), can be linked to in an Entry
  • Collection Entries – ATOM Pub collection of entries (member resources)
  • Collections – A set of deposited entries represented by an Atom Feed document, you can distinguish a collection feed from “a.n.other feed” by the presence of a collection IRI in service document
  • Workspaces – A compartmentilisation concept for repositories, has a name but doesn’t have IRI’s or processing models
  • Service Documents – Groups “Collections” in “Workspaces”, can indicate accepted media types and categories of collections

Next, I found you learn the most by studying the server libraries, what you get is a bundle of java and some set up files for your container. We’ll firstly look at the setup in web.xml

Setup and Servlet mappings (web.xml)

The main servlets (i.e ultimately your rest endpoints) that are defined are…

servicedocument

collection

  • Class: org.swordapp.server.servlets.CollectionServletDefault
  • URL: http://<yourServer>/<yourWebapp>/collection/*
  • Purpose: Retrieveing and deposting to/from collections/feeds and entries

mediaresource

container

statement

The code makes heavy use of interfaces to allow the implementer more freedom to create functionality using the server library in the way they want to, in order to tell the server libraries what code we want to instantiate and what auth. mechanism we will be using, you must set some context parameters to define those settings and implementations used at runtime:

auth

  • param-name: authentication-method
  • param-value: Basic or None (default: “Basic”)

You can set an Authorization header and base64 encode user:password (e.g. try going to a basic auth encoding website and encode “user:password” in plain text box) and send as a header… “Authorization” “Basic dXNlcjpwYXNzd29yZA==”, or, if you prefer set the param-value to “None” for no authorisation. I found (at the time of writing) the default code actually has a bug which means turning the auth off doesn’t work correctly. I found the best way of correcting this was in my own war project (which includes the server libraries as a dependancy) I created a org.swordapp.sever package (where I was implementing the objects needed for the interfaces) and dropped in a copy of the SwordAPIEndpoint.java to override the implementation in the library, I then changed the getAuthCredentials to…

protected AuthCredentials getAuthCredentials(HttpServletRequest request, boolean allowUnauthenticated) throws SwordAuthException
{
   AuthCredentials auth = null;
   String authType = this.config.getAuthType();
   String obo = "";
   this.log.info("Auth type = "+authType);
   //If we are insisting on "a" form of authentication that is not of type "none"
   if(!allowUnauthenticated && !authType.equalsIgnoreCase("none"))
   {
      // Has the user passed authentication details
      String authHeader = request.getHeader("Authorization");
      // Is there an On-Behalf-Of header?
      obo = request.getHeader("On-Behalf-Of");
      // Which authentication scheme do we recognise (should only be Basic)
      boolean isBasic = authType.equalsIgnoreCase("basic");

      if(isBasic && (authHeader == null || authHeader.equals("")))
      {
         throw new SwordAuthException(true);
      }
      // decode the auth header and populate the authcredentials object for return
      String[] userPass = this.decodeAuthHeader(authHeader);
      auth = new AuthCredentials(userPass[0], userPass[1], obo);
   }
   else
   {
      log.debug("No Authentication Credentials supplied/required");
      auth = new AuthCredentials(null, null, obo);
   }
   return auth;
}

The following context parameters set the implementations of interfaces used to implement functionality in the endpoints. However, you are not given default implementations for each of these, so in your war you need to create a new class that implements the respective interface and fill in your functionality….

collection-list-impl

  • param-value: org.swordapp.server.CollectionListManagerImpl
  • Interface it implements: org.swordapp.server.CollectionListManager

service-document-impl

  • param-value: org.swordapp.server.ServiceDocumentManagerImpl
  • Interface it implements: org.swordapp.server.ServiceDocumentManager

collection-list-impl

  • param-value: org.swordapp.server.CollectionListManagerImpl
  • Interface it implements: org.swordapp.server.CollectionListManager

collection-deposit-impl

  • param-value: org.swordapp.server.CollectionDepositManagerImpl
  • Interface it implements: org.swordapp.server.CollectionDepositManager

media-resource-impl

  • param-value: org.swordapp.server.MediaResourceManagerImpl
  • Interface it implements: org.swordapp.server.MediaResourceManager

container-impl

  • param-value: org.swordapp.server.ContainerManagerImpl
  • Interface it implements:  org.swordapp.server.ContainerManager

statement-impl

  • param-value: org.swordapp.server.StatementManagerImpl
  • Interface it implements: org.swordapp.server.StatementManager

config-impl

  • param-value: org.swordapp.server.SwordConfigurationDefault (Yes, this one does have a default implementation in the library you can use)
  • Interface it implements: org.swordapp.server.SwordConfiguration

Endpoint Servlet classes (org.swordapp.server.servlets.*)

Let’s now have a look at the servlets themselves, each servlet contains interfaces which are implemented by loading the classes specified in the web.xml (see above).

All servlets used in the server library extend the “SwordServlet” which (obviously) extends the HttpServlet. Since the SwordServlet contains the server configuration object, all servlets (through inheritance) also hold an implementation of the server configuration (i.e. SwordConfiguration) and a method to allow servlets to load classes from the configuration….

SwordServlet encapsulates:

  • SwordConfiguration interface, instantiated using config-impl
  • loadImplClass() method used for loading implementing classes from tomcat context params

CollectionServletDefault extends SwordServlet and encapsulates:

  • CollectionListManager interface, instantied using collection-list-impl
  • CollectionDepositManager interface, instantied using collection-deposit-impl
  • CollectionAPI object

ServiceDocumentServletDefault extends SwordServlet and encapsulates:

  • ServiceDocumentManager interface, instantiated using service-document-impl
  • ServiceDocumentAPI object

MediaResourceServletDefault extends SwordServlet and encapsulates:

  • MediaResourceManager interface, instantiated using media-resource-impl
  • MediaResourceAPI object

ContainerServletDefault extends SwordServlet and encapsulates:

  • ContainerManager interface, instantiated using container-impl
  • StatementManager interface, instantiated using statement-impl
  • ContainerAPI object

StatementServletDefault extends SwordServlet and encapsulates:

  • StatementManager interface, instantiated using statement-impl
  • StatementAPI object

Endpoint Servlet dependant classes (org.swordapp.server.*)

Those with a keen eye will have noticed that each servlet is also holding an “API” object, these objects fill out the standard Get/Post/Put/Delete HttpServlet methods that the servlets override by taking the configuration object and any interfaces that have been implemented and combine them to do something useful. Similarly to the servlets, they all extend a Sword API super class called “SwordAPIEndpoint”, which holds a SwordConfiguration implementation. The hierarchy (and interfaces they encapsulate) looks like this…

SwordAPIEndpoint

  • SwordConfiguration interface

CollectionAPI extends SwordAPIEndpoint

  • CollectionListManager interface
  • CollectionDepositManager interface

ServiceDocumentAPI extends SwordAPIEndpoint

  • ServiceDocumentManager interface

MediaResourceAPI extends SwordAPIEndpoint

  • MediaResourceManager interface

ContainerAPI extends SwordAPIEndpoint

  • ContainerManager interface
  • StatementManager interface

StatementAPI extends SwordAPIEndpoint

  • StatementManager interface

Implementations of interfaces (org.swordapp.server.*)

I keep mentioning the objects that implement the interfaces, I thought it might be useful to go through in “slightly” more detail what the content of those objects are intended for. Apologies once again, this is not exhaustive as I have not worked my way through what all the methods are intended for:

SwordConfigurationDefault implements org.swordapp.server.SwordConfiguration

  • This is the default object which holds the configuration for the server

CollectionListManagerImpl implements org.swordapp.server.CollectionListManager

CollectionDepositManagerImpl implements org.swordapp.server.CollectionDepositManager

ServiceDocumentManagerImpl implements org.swordpapp.server.ServerDocumentManager

  • Method: getServiceDocument()
  • Accessed via: GET http://<yourServer>/<yourWebapp>/servicedocument/
  • Returns: org.swordapp.server.ServiceDocument
  • Purpose: Serves service documents (xml that explains the contents and deposit policies for the repository(/ies)

MediaResourceManagerImpl implements org.swordapp.server.MediaResourceManager

  • Method: replaceMediaResource()
  • Accessed via: PUT http://<yourServer>/<yourWebapp>/edit-media/
  • Returns: org.swordapp.server.DepositReceipt
  • Purpose: Swap a media resource (pdf/doc etc….) in the repository with the one being “PUT’ed”

ContainerManagerImpl implements org.swordapp.server.ContainerManager

  • Method: replaceMetadataAndMediaResource()
  • Accessed via: PUT http://<yourServer>/<yourWebapp>/edit/
  • Returns: org.swordapp.server.DepositReceipt
  • Purpose: Replaces metadata and media associated with an entry
  • Method: addMetadataAndResources()
  • Accessed via: Does not appear to be “directly” accessible via any specific HTTP request
  • Returns: org.swordapp.server.DepositReceipt
  • Purpose: Not used by the ContainerAPI yet, but presumably it would be for adding a series of entries and associated metadata
  • Method: addResources()
  • Accessed via: Does not appear to be “directly” accessible
  • Returns: org.swordapp.server.DepositReceipt
  • Purpose: Not used by the ContainerAPI yet, but presumably it would be for adding a series of entries
  • Method: useHeaders()
  • Accessed via: POST http://<yourServer>/<yourWebapp>/edit/
  • Returns: org.swordapp.server.DepositReceipt
  • Purpose: Used when depositing only information specified in the HTTP headers, no entry/ies (i.e. no content body to the POST) will have been specified

StatementManagerImpl implements org.swordapp.server.StatementManager

And finally…

Once you have all that setup (and I’d recommend just creating skeleton override methods for the objects implementing interfaces for the time being whilst you figure the code out), you can then start coding the abdera / sword code and try make the client do something. The client itself comes with a handy cli driven (SwordCLI) interface that you can point at your newly created server instance and test the various example methods. I would recommend though, that you comment out the entire list of method references in the main method and go through the list iteratively to slowly make each part of your server work…

As a brief example, if we were to try and get a basic service document to work, try adding this code to your ServiceDocumentManagerImpl.java….

    public ServiceDocument getServiceDocument(String sdUri, AuthCredentials auth, SwordConfiguration config) throws SwordError, SwordServerException, SwordAuthException
    {
        //Our test service document
        ServiceDocument sd = new ServiceDocument();
        //sd.setVersion("2.0");
        sd.setMaxUploadSize(1000000000);

        //Our test workspace
        SwordWorkspace sw = new SwordWorkspace();
        sw.setTitle("TestWorkspace");

        //Our test collection
        SwordCollection sc = new SwordCollection();
        sc.setHref("http://<yourServer>/<yourWebapp>/collection/TestCollection");
        sc.setTitle("TestCollection");
        sc.addAccepts("*/*");
        sc.setCollectionPolicy("TestCollectionPolicy");
        sc.setAbstract("TestCollectionAbstract");
        sc.setMediation(false);
        sc.setTreatment("A human-readable statement describing treatment the deposited resource has received or a URI that dereferences to such a description.");
        sc.addAcceptPackaging("http://purl.org/net/sword/package/SimpleZip");
        sc.addAcceptPackaging("http://purl.org/net/sword/package/METSDSpaceSIP");
        sc.addAcceptPackaging("http://www.ncl.ac.uk/terms/package/html");
        sc.setLocation("http://<yourServer>/<yourWebapp>/collection/TestCollection");
        sc.setMediation(true);
        List iris = new ArrayList();
        iris.add(new IRI("http://<yourServer>/<yourWebapp>/collection/TestCollection/TestSubService"));
        sc.setSubServices(iris);

        //Add collection to workspace
        sw.addCollection(sc);
        //Add workspace to service document
        sd.addWorkspace(sw);

        return sd;
    }

Browsing to http://<yourServer>/<yourWebapp>/collection/ should return something, and removing your comment in your client for the line…

    cli.trySwordServiceDocument()

…should now yield some results (If you just get errors try temporarily turning off the auth. requirement on the server for the purposes of testing).

And that’s the basic principle, you then take the specs and implement the returning and unpackaging of ATOM using the abdera/SWORD objects and link what’s passed/returned to the content found in the system you are trying to integrate.

Further reading

Sword Specs
Brief history of Sword
More useful Sword docs
Another set of slides explaining sword

Andrew Martin
Research and Collaborative Services
Newcastle University

iridium JISC MRD02 – monthly update for August ’12

Progress to date

Workpackage 0 (Project Management)

  • project plan updated to include human support additional planning detail
  • continued discussions on detail of project exit strategy
  • third Steering Group took place on 30 August 2012 (embedding, project transition to institution and data storage needs for iridium project outputs)

Workpackage 1 (Requirements)

  • requirements gathering publish as outputs on website and will be disseminated locally and within JISC MRD Programme
  • resultant project actions drafted for dissemination internally to stakeholders

Workpackage 2 (Policy)

  • no significant changes

Workpackage 3/4/5 (tools, systems, & implementation)

  • DataStage/DataBank evaluated in local infrastructure test installation and initial user testing Oxford-hosted demonstrator
  • DMPOnline external hosting at DCC preference identified and initial testing conducted with iridium support team
  • local Research Data Catalogue (RDC) proof-of-concept tool demonstrated on 21 August 2012 and tested within project team. Second session on 18 September 2012 planned.
  • local e-Science Central tool modifications identified (i.e. Shibboleth authentication) and evaluated by iridium support team
  • discussions with Bath on Sakai VRE and SWORD deposit

Workpackage 6 (Human support)

  • RDM support materials writing day held on 23 August 2012
  • importance of tailoring information to different audiences and signposting material held elsewhere within a Newcastle context identified
  • specific workpackage forward plan written

Workpackage 8 (Evaluation)

  • project evaluation plan expanded with quantitative/qualitative measures, stakeholders and timings
  • JISC Evidence Gatherers’ benefits reviewed
  • evaluation of draft policy principles through FRCs conducted

Workpackage 9 (Dissemination)

  • formal and newsletter style project internal updates drafted
  • Digital Institute project partner submitted poster to Digital Research 2012 (Oxford) on requirements gathering
  • project invited to a specific Academic Unit Research Committee in late October 2012

Activities in the last month

Janet Wheeler attend the Digital Institute’s HPC workshop at Newcastle University

Risks & issues

Risk/issues likely to present in the coming 3 months are:

  • team still needs to be very clear that the iridium project is not about data storage space provision
  • degree of policy revisions that might be required is unknown
  • managing researchers’ expectations about provision of RDM tools
  • uptake of iridium outputs within institutional IT restructuring period

Milestones & challenges

In the coming 3 months, identified milestones are:

  • revision of draft policy documents following consultation with FRCs
  • draft policy approved by URC
  • project outputs (policy, tools and training) evaluated against researcher needs
  • suitable research projects engaged for evaluation of draft outputs
  • planning for project exit strategy

iridium JISC MRD02 – monthly updates June/July ’12

Update for June/July 2012.

Progress to date

Workpackage 0 (Project Management)

  • twice monthly Management Group meetings took place in June and July 2012 to review progress against project plan and active workpackages
  • specific discussion topics included the developing RDM infrastructure and exit/embedding strategy
  • review of workpackages, project tasks and timescales conducted
  • Steering Group arranged for 30 August 2012

Workpackage 1 (Requirements)

  • online survey report reviewed internally
  • interview thematic analysis reviewed internally
  • meeting to write summary of findings and actions to report back to stakeholders held on 23 July 2012

Workpackage 2 (Policy)

  • draft policy and Code of Good Practice out for comment with Faculty Research Committees (FRC)
  • feedback on policy draft expected in September 2012 through University Research Committee (URC)

Workpackage 3/4/5 (tools, systems and implementation)

  • external tools assessment tabulated selection of  tools for further evaluation (e-Science Central, DMP Online, customised Sharepoint, customised SAKAI VRE, and DataFlow)
  • Research Data Catalogue (RDC) prototyping meeting to 20 June 2012 iterative user testing of RDC will take place from 21 August 2012

Workpackage 6 (Human support)

  • mapped existing training for different stakeholders
  • meeting with stakeholders continued
  • training materials writing day planned for 23 August 2012

Workpackage 8 (Evaluation)

  • evaluation plan expanded and iterative testing outlined
  • JISC evidence gatherers’ metrics considered
  • postgraduate student evaluation of MANTRA training through blog posts
  • postgraduate student evaluation of data management plan tools/templates initiated

Workpackage 9 (Dissemination)

  • dissemination page on website updated
  • posters presented at ARMA 2012 and ECRM12

Activities in the last month

  • Janet Wheeler met with Digital Campus Initiative Programme Manager
  • Janet Wheeler, Lindsay Wood and Victor Ottaway met with a related project on data security modelling

Risks & issues

Risk/issues likely to present in the coming 3 months are:

  • team needs to be very clear that the iridium project is not about data storage space provision
  • degree of policy revisions that might be required is unknown
  • managing researchers’ expectations about provision of tools
  • risk that tools identified are not feasible in local environment
  • risk that tools do not adequately meet researchers needs

Milestones & challenges

In the coming 3 months, identified milestones are:

  • revision of draft policy documents following consultation with FRCs
  • draft policy approved by URC
  • project outputs (policy, tools and training) evaluated against researcher needs
  • suitable research projects engaged for evaluation

iridium JISC MRD02 – monthly update May ’12

Progress to date

Workpackage 0 (Project Management)

  • Management Group meetings took place on 10 and 24 of May 2012 to review progress against project plan and active workpackages
  • 2 newly appointed postgraduate support team members aligned to biomedicine inducted and are active on project
  • next Steering Group arranged for 30 August 2012

Workpackage 1 (Requirements)

  • online survey closed on 11 May 2012 with 128 project responses
  • summary report of online survey is being authored
  • findings from thematic analysis of interviews have been reported internally
  • findings will inform use cases for policy, supported by tools and training

Workpackage 2 (Policy)

  • existing policies and guidance have been worked into a draft RDM policy
  • draft policy and Code of Good Practice went to University and Faculty Research Committees (URC and FRCs) for initial consultation
  • recommendations from requirements gathering will be incorporated into draft policy

Workpackage 3/4/5 (Tools, systems and implementation)

  • collation of existing external RDM tool details has been documented
  • working group meeting will be held to gain input on development of research data catalogue (RDC) so far and external outputs interface.
  • iterative user testing of RDC internally and then with researchers is planned from July 2012
  • deployment of e-science central considered and requirements identified

Workpackage 6 (Human support)

  • working group met on 28 and 29 May 2012
  • planning was conducted for consideration of requirements gathering data, external tools, drafting of documentation and mode of delivery for various stakeholders

Workpackage 9 (Dissemination)

  • internal dissemination took place at URF on 30 May 2012
  • posters prepared for ARMA 2012 on June 12-13 2012
  • poster has been drafted for ECRM12 in late June 2012

Activities in the last month

Risks & issues

Risk/issues likely to present in the coming 3 months are:

  • team needs to be very clear that the iridium project is not about data storage space and to manage researchers’ expectations
  • researchers do not give/identify their needs or that researchers’ needs are out of scope
  • project highlights existing practice in data management that requires change

Milestones & challenges

In the coming 3 months, identified milestones are:

  • full RDM requirements identified and analysis published, including use cases
  • exemplar research projects identified and engaged
  • revision of draft policy documents following initial consultation with FRCs
  • postgraduate students project activities management
  • subset of RDM tools and systems assessed and have been identified for taking forward
  • initiation of iterative evaluation of policy, tools and training materials

iridium JISC MRD02 – monthly update April ’12

Progress to date

Workpackage 0 (Project Management)

  • Management Group meetings took place on 12 and 26 of April 2012 to review progress against project plan and active workpackages
  • 2 support team positions were appointed and contracts have been arranged
  • second Steering Group took place on 25 April 2012

Workpackage 1 (Requirements)

  • online survey responses received from 126 research projects
  • 24 face-to-face interviews have been conducted with researchers/related staff and are currently being analysed
  • initial findings are being forwarded to dependant work packages ahead of detailed thematic analysis

Workpackage 2 (Policy)

  • draft RDM policy mapping against existing internal policies and guidance is being carried out
  • draft RDM Code of Good Practice, supporting policy, has been authored and will go to University Research Committee (URC) and then Faculty Research Committees (FRC)

Workpackage 3/4 (Metadata, tools and systems)

  • research data catalogue (RDC) proof-of-concept was demonstrated to team on 20 April 2012
  • RDC allows research management data flows from research projects and research publications to be combined with metadata of research data location and availability
  • the RDC will be developed into a pilot system
  • an existing external RDM tools analysis has been initiated
  • early discussions with Bath University on SWORD2 integration with SAKAI VRE

Workpackage 6 (Human support)

  • working group met on 12 April  and 19 April 2012
  • detailed workpackage planning was conducted including what needs to be communicated, the methods with which to communicate and the stakeholder group with which to communicate to
  • workpackage leader has met with 2 Deans of Postgraduate Studies

Workpackage 9 (Dissemination)

  • project was represented at DCC North East event
  • posters are being prepared for ECRM12 and ARMA in June 2012
  • internal dissemination at University Research Forum on 30 May 2012 is planned
  • dissemination plan will be extended with recent guidance form Steering Group

Activities in the last month

  • Lindsay Wood and John Williams attended RLUK RDM meeting on 16 April 2012

Risks & issues

Risk/issues likely to present in the coming 3 months are:

  • team needs to be very clear that the iridium project is not about data storage space and to manage researchers’ expectations
  • researchers do not give/identify their needs or that researchers’ needs are out of scope
  • project highlights existing practice in data management that requires change

Milestones & challenges

In the coming 3 months, identified milestones are:

  • RDM requirements identified and analysis published, including use cases
  • exemplar research projects identified and engaged
  • a detailed RDM draft policy document, consolidated using the analysis of existing policies is reviewed by FRC and URC
  • postgraduate student support team project activities management
  • RDM tools and systems have been identified and assessed
%d bloggers like this: