JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for JISC-REPOSITORIES Archives


JISC-REPOSITORIES Archives

JISC-REPOSITORIES Archives


JISC-REPOSITORIES@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

JISC-REPOSITORIES Home

JISC-REPOSITORIES Home

JISC-REPOSITORIES  March 2009

JISC-REPOSITORIES March 2009

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Repositories vs Source code repositories

From:

Jim Tuttle <[log in to unmask]>

Reply-To:

Jim Tuttle <[log in to unmask]>

Date:

Fri, 13 Mar 2009 09:29:12 -0400

Content-Type:

multipart/signed

Parts/Attachments:

Parts/Attachments

text/plain (105 lines) , signature.asc (105 lines)

I've also been thinking about how to move upstream in the workflow of
campus data creators and publishers.  This is the suggestion of the
University of Rochester's paper, Understanding Faculty to Improve
Content Recruitment for Institutional Repositories.  Enabling
collaborative work among researchers from disparate units or
universities seems an obvious niche.

One of the obstacles to offering versioned scratch space (isn't that the
essence of a repository space for versioning of objects prior to the
objects being declared final?) for us is the probable space requirement
to store multiple versions of objects.  This is, as I understand it,
what University of Hull and University of Prince Edward Island are doing
with Virtual Research Environments- offering uncurated, versioned,
collaboration-enabled space under the assumption that moving finalized
objects into the repository will be extremely simple.

By applying delta technology to save only changes, perhaps space
considerations can be mitigated.  I would worry that recreating a
specific intermediate state of an object, should the system fail, would
be that much more complicated, though.

I think you raise a separate question about derivative data and managing
relationships.  In the context of archiving geospatial data, we've been
thinking about applying a FRBR model to collections and constituent
objects.  Ideally, we'd like to embed a persistent identifier in the
metadata of each object that resolves to a relationship record.  It
seems especially useful in light of the temporal aspect of our content.

Thanks for raising the topic,



Chris Rusbridge wrote:
> My earlier note about how the R word was mostly being used for something
> else, and in particular for source code version control repositories,
> has been swirling around in the back of my brain for a few days, bumping
> into other stuff. In particular, I began to wonder whether there are
> elements of the typical source code repository that we could usefully
> use for our repositories. Now this thought is neither new nor original;
> I remember commenting in a blog post in August last year on Peter
> Murray-Rust's epiphany from April 2007
> (http://wwmm.ch.cam.ac.uk/blogs/murrayrust/?p=259) that SourceForge was
> a repository. But I don't think I've seen the ideas contrasted yet, say
> in the context of what IRs could usefully take from source code
> repositories.
> 
> A lot of what goes into source code repositories is about managing
> change: keeping track of versions, and ensuring that separate people are
> not changing the same element at the same time. There are also
> presumably sophisticated facilities for constructing what one might call
> derivative products (compiled versions, libraries, etc; it's a long time
> since I used one of these things in production!).
> 
> IRs and related repositories have traditionally not been about change;
> they tend to be about maintaining a static version (I won't say
> "preserving", as it appears some object to that idea). However, the idea
> of moving the repository upstream into the researcher's workflow, as in
> the idea of a Research Repository System (eg
> http://digitalcuration.blogspot.com/2008/07/negative-click-positive-value-research.html).
> This does imply managing change much more. Besides, we're beginning to
> be troubled by multiple version problems, and we certainly have
> derivative products (from simple Word -> PDF transformations, to more
> unclear pre-print -> post-print relationships).
> 
> So my question is: has this comparison of IR platforms to source code
> repository systems been done, or is anyone doing it?
> 
> -- 
> Chris Rusbridge
> Director, Digital Curation Centre
> Email: [log in to unmask]    Phone 0131 6513823
> University of Edinburgh
> Appleton Tower, Crichton St, Edinburgh EH8 9LE
> 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> 
> On 10 Mar 2009, at 17:44, Chris Rusbridge wrote:
> 
>> I have [a twitter search] for "Repository OR Repositories". I just did
>> a quick count; with around 160 tweets found in the past 2 days
>> containing one of those words, only 14 had anything to do with the
>> sort of repositories this list is interested in!
>>>
>>
>> Most of the rest appear to be to do with SVN and git etc  version
>> control repositories. Quite a lot appear to be the simple dictionary
>> meaning of places to store something.
>>
>> I hadn't quite realised how much we are overloading someone else's
>> vocabulary with the R-word!

-- 
----------------------------
Jim Tuttle
Digital Repository Librarian
Digital Library Initiatives
NCSU Libraries
919.513.0651



Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
November 2005
October 2005


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager