[
https://jira.duraspace.org/browse/DS-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-1348:
----------------------------
Fix Version/s: (was: 3.0)
This ticket sounds like a longer term discussion that may need to happen, so I
don't think there's anything that can be resolved in time for 3.0. (So, I've
taken the "fix by 3.0" off this ticket)
However, this does bring up the notion that how Versioning uses handles is
*not* actually documented anywhere. I'm looking at the 3.x docs and don't see
any mention of the"n.1" or "n.2" version handles anywhere.
https://wiki.duraspace.org/display/DSDOC3x/Item+Level+Versioning
So, it would be nice to see examples about what handles are generated or
assigned (similar to what Mark has written above) when an Item is versioned.
Documenting how the handles are assigned to new versions may actually help to
clarify whether there is an issue of persistence here or not. If I'm
understanding what is written above by Claudia & Mark, it sounds like there may
actually just be a misunderstanding that could be cleared up by better
documentation.
> Item level versioning breaks persistence and lacks meta information
> -------------------------------------------------------------------
>
> Key: DS-1348
> URL: https://jira.duraspace.org/browse/DS-1348
> Project: DSpace
> Issue Type: Bug
> Components: XMLUI
> Affects Versions: 3.0
> Reporter: Claudia Jürgen
> Priority: Major
>
> At the moment the item level versioning breaks the concept of persistent
> identifiers as an item gets a new handle assigned during versioning, e.g.
> Create an item
> -> it gets baseHandle/n
> Version this item
> -> the new version gets baseHandle/n
> -> the original version gets baseHandle/n.1
> Version it again
> -> the new version gets baseHandle/n
> -> the second version gets baseHandle/n.2
> -> the original version gets baseHandle/n.1
> and so on
> With regards to relationship services and versioning (here is some
> information about persistent identifier and value added services
> http://www.ands.org.au/guides/persistent-identifiers-expert.html#_sec331)
> relationship services can provide identifiers which encompass all versions of
> an item. So it should be something like that
> Create an item
> -> the encompassing identifier baseHandle/n is created
> -> the item gets an identifier baseHandle/n.1
> -> the baseHandle/n encompasses baseHandle/n.1 and identifies it as the
> newest and only version
> Create a new version
> -> the new version gets identifier baseHandle/n.2
> -> the baseHandle/n encompasses baseHandle/n.1 and baseHandle/n.2 and points
> to baseHandle/n.2 as the newest version
> One other can of worms is how to handle the base identifier which encompasses
> all the versions. It's like a container for items and not an item itself.
> Metadata:
> a) items not connected via metadata
> The versioned items are not linked via metadata elements like hasVersion,
> isVersionOf, replaces, isReplacedBy. So e.g. harvesting a versioned item via
> OAI-PMH gives no clue, that it is versioned at all.
> b) dc.date.issued does not change
> Each version of an item got the same dc.date.issued
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
