[
https://jira.duraspace.org/browse/DS-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26929#comment-26929
]
Bram Luyten (@mire) commented on DS-1348:
-----------------------------------------
On the topic of persistence:
Am I right when I synthesize your train of thought that you say that design is
flawed in the sense that we don't need the concept of a canonical identifier,
but that a "base" identifier should rather point to a container that links to
all the versions?
I feel you might be going too far in stating that the idea of a canonical
Identifier "breaks" persistence. It will always be a persistent link the the
latest, repository manager approved version of the item. If people deliberately
want to link to an older version, they can. But the base assumption is that by
linking to the /n identifier, they get the most updated one.
Let's take the case of embargoed items: In the current, non versioned,
implementation of the embargo, a bitstream becomes public once the embargo
expires. Consider a user who linked to the item page, before the fulltext was
public. Would you consider it "breaking of persistence" that a user is no
longer able to retrieve the item without the fulltext, once the embargo expires?
I'm also wondering whether we're not just having a discussion on semantics
here: if the /n identifier in the current implementation of versioning first
lists the metadata for the most recent version, followed by the links to the
older versions, don't you already have the "container" you needed?
On metadata:
- I do agree that it would be useful to expose the links to the different
versions in the DC fields you mention
- dc.date.issued seems indeed unchanged, but dc.date.available and
dc.date.accessioned are changed. If dc.date.issued represents the original
publication date of the paper/document corresponding with the item, I don't
think it should be mandatory changed in a new version. Of course, a submitter
could change this in the creation of a new version, just like her or she can
change any field?
> 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
