Hi David,

I think you shouldn’t distinguish between an item and a bitstream in the way 
you’re doing. An Item is a container for files (bitstreams) and descriptive 
meta data (meta data fields of an item). Together they form some kind of unit 
(a publication, a dataset, …). If you change a bitstream you should also change 
at least some of the item metadata, e.g. a date field when this version was 
publicly available for the first time. Following this argumentation it doesn’t 
make sense to have versioning “for a bitstream only” nor “for an item only”. 
Out of my point of view the Item level versioning is exactly what you are 
looking for: a possibility to distinguish different versions of a “publication” 
linking on each other.

With DSpace 6 we will change the VersionedHandleIdentifierProvider (the old 
behavior will be kept as 
VersionedHandleIdentifierProviderWithCanonicalHandles). Before DSpace 6 the 
VersionedHandleIdentifierProvider assured that the handle of an item was always 
pointing to the newest version of the item. When a newer version was published 
the previous version got a new handle and the initial handle was pointing on 
the newest version. This makes it impossible to cite the currently newest 
version as the handle of a specific version changes when it isn’t anymore the 
newest one. Beginning with DSpace 6 every version keeps is handle and every new 
version get a new unique handle. I still have to write more about this in the 
DSpace 6 documentation and will do so within the next days. Please give me a 
note if you want to no more about this.

Here is another example using DOIs (the VerionedDOIIdentifierProvider will also 
be a part of DSpace 6):

-          Version 6: http://dx.doi.org/10.14279/depositonce-87.6

-          Version 4 and 5 were never published for unkown reasons

-          Version 3: http://dx.doi.org/10.14279/depositonce-87.3

-          … (you can find older Versions linked in the version history of 
newer ones)

Regards,
  Pascal

From: [email protected] 
[mailto:[email protected]] On Behalf Of Andrea Schweer
Sent: Wednesday, April 20, 2016 7:14 AM
To: David Palmer <[email protected]>; [email protected]
Subject: Re: [dspace-community] DSpace versioning ?

Hi David,
On 20/04/16 16:45, David Palmer wrote:
>From reading this,
   https://wiki.duraspace.org/display/DSDOC3x/Item+Level+Versioning

It appears that the ITEM in DSpace can be versioned.  But the individual 
bitstreams cannot.   So if we wanted to show a new version of a bitstream, we 
would have to make a new item for it.

>From a purely technical point of view, there is nothing stopping you from 
>adding a second bitstream to the existing, live item. You'll need to decide 
>whether this is likely to confuse your users in a scenario where someone may 
>have cited the item when only the first bitstream was present, but the second 
>bitstream is present when a reader of that publication visits the item. Plus 
>any considerations whether the T&Cs of the repository cover modifications to 
>live items etc. You might also want to think about having a custom metadata 
>field that is shown on the item page and explains the file history of the item.


I believe this would then become very confusing in the public display.  Are 
there examples of this to view?

I'm not sure specifically what examples you're asking about -- versioned items? 
Here is one:
current version: https://ourarchive.otago.ac.nz/handle/10523/717
older version: https://ourarchive.otago.ac.nz/handle/10523/759
(this isn't quite using the stock versioning code, but display of stock 
versioned items should be similar)

In this case, both versions just have one bitstream though.

If you go with versioning in your scenario, you might want to think about / 
discuss with your content authors (as presumable domain experts) whether end 
users would want to see all versions of the bitstream on the most current 
version of the item versus having multiple versions of the item, each with just 
one bitstream (so you'd have to go to an older version of the item if you 
wanted to see an older version of the bitstream).

cheers,
Andrea


--

Dr Andrea Schweer

Lead Software Developer, ITS Information Systems

The University of Waikato, Hamilton, New Zealand

+64-7-837 9120
--
You received this message because you are subscribed to the Google Groups 
"DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
[email protected]<mailto:[email protected]>.
To post to this group, send email to 
[email protected]<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/dspace-community.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/dspace-community.
For more options, visit https://groups.google.com/d/optout.

Reply via email to