[
https://jira.duraspace.org/browse/DS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19577#action_19577
]
Kim Shepherd commented on DS-862:
---------------------------------
@Mark - totally agree. Bitstream ID instead of filename as the derived name
makes sense to me.
Example: cases where a thesis or published article is found to have copyright
or defamatory material and is replaced with a redacted version with the same
filename. If bitstream IDs were used instead of filenames, it would be apparent
to a repository manager (and filter-media) upon inspection of the bundles that
the extracted fulltext needed replacing. The filename could still be kept as a
hint in the description field.
Perhaps this could be looked at when we start the "all DSOs can have full
metadata" work?
> Add ability to rename bitstreams (filenames) in XMLUI
> -----------------------------------------------------
>
> Key: DS-862
> URL: https://jira.duraspace.org/browse/DS-862
> Project: DSpace
> Issue Type: Improvement
> Components: XMLUI
> Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1
> Reporter: Kim Shepherd
> Assignee: Kim Shepherd
> Fix For: 1.8.0
>
> Attachments: [DS-862]_ability_to_rename_file_names_in_XMLUI.patch
>
>
> Add ability to edit a bitstream's filename as well as description, format,
> etc. in XMLUI's EditBitstream form.
> This is a trivial change and helps keep parity with JSPUI. There are
> implications to renaming bitstreams -- none severe, but worth considering.
> 1. Bitstream links are usually displayed with the filename included.
> Since handle and sequence ID are what actually matches the request to the
> item+bitstream, this is not a problem. Old/cached/indexed links will still
> work.
> For this reason, editing bitstream filename in the EditBitstream form is
> actually safer than deleting and re-uploading the bitstream, which would
> generate a new sequence ID and cause old links to be unusable (a lot of
> repository managers use this as a workaround currently)
> 2. Bitstreams derived from filter-media processes (eg.
> THUMBNAIL/image.jpg.jpg and TEXT/document.txt.txt) will, in practice, become
> orphaned, and on the next filter-media run, the derived bitstreams will be
> regenerated and added to the TEXT, THUMBNAIL. etc. bundles. This is
> potentially a problem, in terms of storage space, search term boosting,
> thumbnail duplication could affect display of item lists, and so on.
> It could be possible to programatically search for the derived bitstreams
> (eg. search for oldname.*.txt) and rename to fit the renaming of the ORIGINAL
> bitstream, but my opinion is that this is something that should be left up to
> repository managers/administrators, and that as long as we clearly document a
> recommended renaming procedure (we could even display a javascript warning
> alert or something, if necessary), the "human touch" will always be better
> than the interface trying to guess what other bitstreams to touch.
> Attaching patch that's tested internally at my institution, but will not
> commit until vote at dev meeting has been taken and others have had a chance
> to comment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
