[Dspace-general] Ability to replace existing items

Wed Jan 26 10:52:14 EST 2005

Yes! And this is possible to do now within the metadata (i.e. forward and 
backward links
to new/old versions using their Handles, and with the default being the 
latest).
Hopefully a future version of DSpace will handle versions more elegantly in 
the UI,
but the basic concept of multiple versions all being accessible is one that 
I really like.

MacKenzie

At 08:41 AM 1/26/2005 -0500, John Preston wrote:
>Wouldn't a good compromise be to have some versioning info with objects
>that would indicate that this is a more recent version of an original
>and possibly some info on when it was checked in, etc.
>
>We have the need for this with LO's
>
>John
>
>On Wed, 2005-01-26 at 00:54 -0500, MacKenzie Smith wrote:
> > As is so often the case, this is *not* a technical issue... DSpace is 
> quite
> > capable of supporting file replacements
> > via several means, include direct sql calls to the database (as we've had
> > to do on occaision to clean up messes).
> > Rather this is a local *policy* issue, and it has several important
> > consequences.... for one thing the associated
> > metadata can get messed up (e.g. the checksums and other technical
> > properties of the file) if they aren't also
> > regenerated when the replacement is deposited.
> >
> > The other *major* problem with allowing replacements is the whole 
> long-term
> > persistence and preservation
> > commitment that some of us are making to our community... if someone
> > submits a paper to DSpace and it
> > gets a Handle, then someone else cites that paper in DSpace using that
> > Handle, then the author decides to
> > submit a different version of his paper and *replaces* the original, the
> > citer is out of luck -- the new version
> > might invalidate her conclusions in the citing document and *no one will
> > ever know that the cited work is not
> > the original one that she read*. In other words, you're toying with the
> > scholarly record. When faculty have asked
> > us to change our no replacement policy and we've talked them through this
> > example they often concur that it
> > would be better to keep all versions.
> >
> > However, I can see that while published papers probably shouldn't be
> > replaced willy nilly, since they're part
> > of the permanent scholarly record, a learning object or other item that is
> > more ephemeral in nature might not
> > require such strict policies. Up to you...
> >
> > MacKenzie
> >
> >
> > At 12:34 PM 1/25/2005 -0500, Sam Kalb wrote:
> > >I agree that this capability is a significant need.  Not only for 
> learning
> > >objects but for other types of documents.
> > >Sam
> > >
> > >>Date: Mon, 24 Jan 2005 14:12:23 -0500
> > >>From: "Petsche, Kevin F" <kpetsche at iupui.edu>
> > >>To: <dspace-general at mit.edu>
> > >>Subject: [Dspace-general] Ability to replace existing items
> > >>Message-ID:
> > >><37EECABFDCD02B47A114618423A57FAD0238CDD8 at iu-mssg-mbx03.exchange.iu.edu>
> > >>Content-Type: multipart/alternative;
> > >>         boundary="----_=_NextPart_001_01C50248.A27BFDDD"
> > >>MIME-Version: 1.0
> > >>Precedence: list
> > >>Message: 1
> > >>
> > >>This is a multi-part message in MIME format.
> > >>
> > >>------_=_NextPart_001_01C50248.A27BFDDD
> > >>Content-Type: text/plain;
> > >>         charset="us-ascii"
> > >>Content-Transfer-Encoding: quoted-printable
> > >>
> > >>Hi,
> > >>
> > >>=20
> > >>
> > >>I was just reading through Beatrix's post and MacKenzie's reply about
> > >>replacing an already submitted item (and thus maintaining its handle).
> > >>Am I to conclude that the only way to do this, then, is through the
> > >>import process? =20
> > >>
> > >>=20
> > >>
> > >>This is a significant need, I believe, if DSpace is to become a
> > >>functioning repository for reusable learning objects RLO's).  We're
> > >>getting ready to engage a few communities here about this, but it seems
> > >>that these RLO's are too dynamic (i.e. they're constantly being updated
> > >>by their creators) to expect communities to go through the full
> > >>submission process each time they make an update.  =20
> > >>
> > >>=20
> > >>
> > >>Also, where is there documentation about the import process? =20
> > >>
> > >>=20
> > >>
> > >>Thanks,=20
> > >>
> > >>=20
> > >>
> > >>Kevin Petsche
> > >>
> > >>Electronic Journals Collection Manager
> > >>
> > >>IUPUI University Library
> > >>
> > >>UL1115K
> > >>
> > >>755 W. Michigan Street
> > >>
> > >>Indianapolis, IN  46202-5196
> > >>
> > >>317.278.2330 (Office)
> > >>
> > >>317.278.0368 (Fax)
> > >>
> > >>=20
> > >>
> > >>< mailto:kpetsche at iupui.edu> kpetsche at iupui.edu
> > >>
> > >>=20
> > >>
> > >>
> > >>------_=_NextPart_001_01C50248.A27BFDDD
> > >>Content-Type: text/html;
> > >>         charset="us-ascii"
> > >>Content-Transfer-Encoding: quoted-printable
> > >>
> > >>Hi,
> > >>
> > >>
> > >>
> > >>I was just reading through Beatrix's post and = MacKenzie's reply about
> > >>replacing an already submitted item (and thus maintaining = its
> > >>handle).  Am I to conclude that the only way to do this, then, is =
> > >>through the import process?
> > >>
> > >>
> > >>
> > >>This is a significant need, I believe, if DSpace is = to become a
> > >>functioning repository for reusable learning objects = RLO's).  We're
> > >>getting ready to engage a few communities here about this, but it 
> seems =
> > >>that these RLO's are too dynamic (i.e. they're constantly being = 
> updated
> > >>by their creators) to expect communities to go through the full =
> > >>submission process each time they make an update.  =
> > >>
> > >>
> > >>
> > >>Also, where is there documentation about the import process?
> > >>
> > >>
> > >>
> > >>Thanks,
> > >>
> > >>
> > >>
> > >>Kevin = Petsche
> > >>
> > >>Electronic Journals Collection = Manager
> > >>
> > >>IUPUI<= /st1:place> University = Library
> > >>
> > >>UL1115K
> > >>=
> > >>
> > >>755 W. Michigan = Street
> > >>
> > >>Indianapolis, IN  = 46202-5196
> > >>
> > >>317.278.2330 = (Office)
> > >>
> > >>317.278.0368 = (Fax)
> > >>
> > >>
> > >>
> > >>kpetsche at iupui.edu
> > >>
> > >>
> > >>
> > >>------_=_NextPart_001_01C50248.A27BFDDD--
> > >>------------------------------
> > >
> > >----------------------------------------------------------------------
> > >Sam Kalb
> > >Library Assessment & IT Projects Coordinator,
> > >Queen's University Libraries
> > >Kingston, Ontario, Canada  K7L 5C4
> > >Phone: (613) 533-2830; Fax: (613) 533-6362
> > >Email: kalbs at post.queensu.ca
> > >_______________________________________________
> > >Dspace-general mailing list
> > >Dspace-general at mit.edu
> > >http://mailman.mit.edu/mailman/listinfo/dspace-general