Antony Corfield [awc] wrote:
> 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.
I think that one of the factors in this is that the repository is seen
as an end-user database for displaying things, where there is an
emphasis on "archive" rather than "repository", where each state is a
distinct and inviolate thing that needs to be maintained as distinct
from past and future incarnations.
Yes, there is a need to be able to manipulate the content held in a
research database more easily, but this is at odd with the "archive"
premis above.
I have a personal belief that the current repository concept is flawed,
and that institutions should provide a repository for "work in
progress", complete with descriptive data to associate it with the
appropriate research grants, researchers, departments, funders, etc.
I believe that the thing we call an "institutional repository" should be
a slice into this data-corpus, not a database in it's own right.
In this approach, one can use the likes of Google Docs for document
editing... which provides versioning and so forth :)
--
Ian Stuart.
Developer, the Depot
EDINA,
The University of Edinburgh.
http://edina.ac.uk/
|