> -----Original Message-----
> From: Repositories discussion list [mailto:[log in to unmask]]
> On Behalf Of John Smith
> Sent: 06 March 2008 18:59
> To: [log in to unmask]
> Subject: Re: OA IRs Are Research Access Providers, Not Publishers or Library
> Collections
> 
> Les,
> 
> > -----Original Message-----
> > From: Leslie Carr [mailto:[log in to unmask]]
> > Sent: 06 March 2008 08:36
> >
> > On 5 Mar 2008, at 19:03, John Smith wrote:
> >
> > > Under this view metadata is not a description of the content of
> > > the repository it is a description of a research output which
> > > may have a version of that output attached to it.
> 
> > Is a repository used by librarians to describe 'files' that they
> > 'have', or is it used by researchers to describe 'work' that they
> > have 'done'?
> 
> I am not attempting to dictate what an IR is I am seeking clarity as to what
> it is and what it will be used for in the future.
> 
> I have the job of building Kent's IR and I want to be clear about what it is
> I am doing. I started building KAR (Kent Academic Repository) back in 2006
> following the repository model I was taught at JISC supported workshops in
> Southampton and London. We too were pulled off-course by the demands of the
> RAE and I was also fooled by the Sirens promise, that 'if we put up the bib
> records they/we will add the text later', now I'm not so sure.
> 
> We now have a demand for re-use of the IR data to provide annual research
> reports and individual/departmental publication lists, etc. This makes it
> difficult to use the multiple records per item model that I was told was best
> practise.
> 
> 
> It seems to me the easiest way to square this circle is to adopt a one record
> per item model with multiple versions attached (in order to provide the
> repository requirements).To do this cleanly I would like to be able to

Versioning is certainly one area where the current IR platforms (Eprints, Dspace, Fedora) require further development.

Software engineers have been using repositories or versioning systems for many years (e.g. cvs http://www.nongnu.org/cvs/  and svn http://subversion.tigris.org/ ) where code (content) can be modified by authors and each version saved with comments. Team integration, roll back to previous versions and branches offering different flavours and tagged releases (publication) are at the core of versioning systems.

Whilst IRs may be seen more as content (and metadata) archives where the 'finished article' can be made available, a common framework for versioning which incorporates some of the above would be desirable.


Regards,
Antony
--
Antony Corfield
ROAD Project
http://road.aber.ac.uk
tel. 01970 628724

> completely hide any version held (i.e., make visible only those versions I
> choose). By hide I don't mean restrict access I mean make completely
> invisible. Currently I don't seem to be able to do this with EPrints. I also
> need to clearly separate the metadata that describes the item from the
> metadata that describes the full text (where there is any) that will be
> delivered if requested. I also need a way to make this difference clear to
> any harvester.
> 
> You mention that
> 
> > The VERSIONS metadata will be a standard part of EPrints 3.1
> 
> Will this enable me to do what I outline above? Also, when will 3.1 be
> available? I'm building a real repository with currently ~2000 items. The
> bigger it gets the harder it will be to re-design it.
> 
> 
> Despite Stevan's comments I believe getting agreement on this matter is
> important. Obviously more content in IRs is essential but this alone is not
> enough. If we all build IRs with different contents and internal organisation
> we will not be able to use IRs as the basis of the scaleable trustworthy full
> text delivery system that he needs 'to free the academic literature'.
> 
> Regards,
> 
> John.