[
https://jira.duraspace.org/browse/DS-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26999#comment-26999
]
Mark Diggory commented on DS-1348:
----------------------------------
1.) The current strategy was presented to the community approximately 5 months
ago after OR12 and this is the first case that anyone challenged the strategy.
The points are important for discussion and they are welcomed.
2.) The strategy is not written in stone, the primary objective of the
"Versioning and Identifier Services" is that different logic for versioning can
be easily customized or reimplemented by developers, while sustaining the
appropriate hooks into the system for creating new versions and processing them
through the workflow.
There are currently two Handle Identifier services present, on creates handles
with the version encoded, the second create opaque handles for each version,
converting the original handle to be the version history ID, the use of either
is configurable.
> Create an item
> -> it gets baseHandle/n
> Version this item
> -> the new version gets baseHandle/n
> -> the original version gets baseHandle/n.1
This is partially correct, the new version gets both "n" and "n.2" in this case.
> 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
At this point there are three versions, the latest would be "n.3" and "n" would
resolve to it, not n.2
> 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
The only difference between this and the current behavior is that rather than
having to introduce some form of batch processing to populate the
versionhistory table for all the original Items, n.1 is assumed and only
created when differentiation is needed, i.e. when the first request for a new
version is made. If there is a desire to make n.1 exist by default and be
resolvable, then we can create a script to pre-populate the table and adjust
the versioning code to assure that n.1 is always present and exists. This a
rather small adjustment IMO.
3.) Per adding metadata for isVersionOf/hasVersion. This was intentionally
avoided because of both the complexity and brittleness of storing such data in
parallel in the Item metadata, it also requires that we actually "change" the
original item to add the metadata into it, which breaks the concept of
versioning not actually causing any changes the original item.
The design recommendation for future support of versioning metadata in the item
is that it be "system level metadata" that is automatically added to exported
records such that anyone editing the metadata record is not at risk of breaking
the versioning hierarchy. So the recommendation is that we wait until new
metadata support for DSpace is engineered, this support should include the
capability to create more "sections" of metadata other than the one flat
description. Versioning metadata would be stored in an administrative metadata
section of the METS and not the current descriptive metadata.
5.) OAI is tracking the most current revision of the item and exposing it as an
updated record. From the standpoint of the consumers of OAI resources, this is
no different than previous behavior if one were editing an item. As we see that
OAI was completely replaced in 3.0, including any revision history into it was
a considerable moving target. The recommendation for dealing with this is that
improvements to both versioning and OAI be made fo 3.1 and 4.0 now that we are
approaching a final stable release of 3.0. Given the agreement that versioning
be disabled by default and easily turned on in 3.0, the stage is now set for
making these improvements.
6.) It is not clear in your description, how the approach of moving the
canonical handle actually breaks persistence. We need to be clear, it is the
Identifier that is persistent, such that it can be placed into citations and an
intended resource is still resolvable. It is not the intention of persistent
identification that the resource (that a PID resolves to) cannot be moved or
changed. In fact, that was the original intent in the design of the handle
system, that moving/replacing the resource referred to by a handle would be
possible without breaking the underlying citability of that resource.
I would like to clarify that Item Level Versioning is not intended to replace
the contents of an Item with new contents that are logically or conceptually
different from the original. The goal is to allow the curator to publish
changes to the Item in a manner that the original published version of the Item
is still available and accessible. The important "use case" for this has to do
with Data Management, here it is important that if research is published on a
specific dataset, and something is identified as incorrect concerning that
dataset, it is possible to publish a corrected revision of the dataset for
future use while retaining the original that was referenced in the citations.
In such a case, it would be important to be able to adjust everything,
including the metadata to reflect that changes that may need to be recorded in
that new revision. The versioning support is intended to make it the point
that both versions of the dataset are "viable digital resources" that need to
be persistently identified. The goal is not to decrease persistence, but to
increase it, allowing the curator to actually retain the previous state of the
Item when making changes to it.
> 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
> Fix For: 3.0
>
>
> 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
