[Dspace-general] Ability to replace existing items

[MacKenzie Smith]

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

MacKenzie Smith
Associate Director for Technology
MIT Libraries
Building E25-131d
77 Massachusetts Avenue
Cambridge, MA  02139
(617)253-8184
kenzie at mit.edu