Powered By IdeaScale - try it free Login/Signup

Repositories - communicating the idea

« Back To JISC Repositories
Repository is associated with a persistent storage system
Posted by c.rusbridge 07/14/2008 07:00 AM GMT+00:00
OK, I'll go the whole hog in relation to the RRS blog posts:

At a very basic level, the RRS should [be associated with] a Persistent Storage service. Completely agnostic as to objects, Persistent Storage would provide a personal, or group-oriented (ie within the institution) or project-oriented (ie beyond the institution) storage service that is properly backed up. There’s no claim that Persistent Storage would last for ever, but it must last beyond the next power spike, virus infection or laptop loss! It has to be easy to use, as simple as mounting a virtual drive (but has to work equally easily for researchers using all 3 common OS environments). Conversely (and this isn’t easy), there must be reliable ways of taking parts of it with you when away from base, so synchronisation with laptops or remote computers is essential. It should support anything: data, documents, ancillary objects, databases, whatever you need. It’s possible that “cloud computing” eg Amazon S3, the Carmen Cloud or other GRID services might be appropriate.
Idea # 23Category/Tags : Repository functions (10)  (9)  
Comments
rachel.heery
07/15/2008
Chris, I am posting a comment on this 'idea' though it applies really to the combined set of your ideas. I think the RRS you envisage sounds fantastic and would be a 'good thing', what worries me is the 'function creep' taking us a few miles on from some of the more basic, simpler 'few keystrokes' approach to repositories. The RRS sounds to have many features of a Virtual Research Environment, albeit perhaps a less data centric VRE, maybe more a VRE for the humanities and social science? I am wondering, should we be thinking about repository activity (funding!) in the JISC context as integral with VRE activity? or do we concentrate on the 'simple repository' until we have widespread uptake? I notice that the Intute Repository Search project sees integration with VRE as 'stage 3' in their plan, http://www.jisc.ac.uk/media/documents/events/2007/06/vic_lyte.pdf so maybe the answer is to keep integration with full blown VRE as longer term goal, meaning we need to start to take on board how the repository supports a VRE. Or following your line of thinking, is the repository equivalent to the VRE? I think de facto there are already other systems within research uni's that would need to be combined to establish the VRE (authoring sysstems, document management, data storage, research info) so maybe the repository can mature as a simpler organism a bit longer??
Rachel Heery
Paul Walk
07/17/2008
Chris,
Responding to this particular idea - actually two ideas: persistence and what I interpret as 'offline synchronisation'.

I agree that persistence, more or less as you define it here, should be a core property of what I think of as a 'source repository'. In terms of ease of use: read, or 'get' access should be simple and should be provided through HTTP unless there is a very good reason not to. We should aspire to ease of use in terms of ingest and administrative activities.

In terms of synchronisation with offline storage (unless I have misunderstood your point): this is an interesting area, but I'm not sure it is a fundamental or universal function of 'the repository'. I think we are going to see a strange race between the development of mechanisms to do this (e.g. GoogleGears) and the progress in us all becoming so ubiquitously and permanently connected that we don't need this any more.....

Paul Walk
c.rusbridge
07/17/2008
@rachel, I wasn't thinking of VREs when I wrote the original blog posts, mainly because I've never really grasped the functionality they might offer. I'll try to have a think about the relationship. My immediate gut reaction relates to something I wrote in the blog posts but maybe not here: I didn't want to propose a complex, monolithic system (and I tend to think a VRE fits in that bag) but something more component-like...

@paul, I think I see this persistent storage bit as being associated with rather than necessarily part of the repository. I think maybe here I was responding to the well-known poor quality of storage management in research groups, and wanting to add something to help, but maybe it's not really part of the repository it...
Files/Attachments
Related Topics/Ideas
Title

Category/Tags : Repository functions (10)  (9)  

Category/Tags : Repository functions (10)  (9)  

Category/Tags : Repository functions (10)  (9)  

Category/Tags : Repository functions (10)  (9)  

Category/Tags : Repository functions (10)  (9)  

Category/Tags : Repository functions (10)  (9)  

Category/Tags : Repository functions (10)  (9)  

Activity Chart
Track/Publish/Promote
  • Users Tracking (3)
Privacy Policy   |   Terms of Use
Idea Management