[
https://jira.duraspace.org/browse/DS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22083#comment-22083
]
Richard Rodgers commented on DS-996:
------------------------------------
A few further comments, generally responding to MarkD & MarkW.
I share Mark D's concern that we have a tendency to make Item metadata the
Procrustean bed into which we force everything, but I'm not convinced that
expanding the Item definition is preferable: for better or worse, this really
amounts to a data model change, and the consequences are significant. Unlike
metadata, a change like this is neither extensible, nor optional. I'm less
worried about one-time schema upgrades than I am that a lot of application
logic is invalidated. For example, all UIs will have to wire in new logic to
expose and/or modify this field. Anything that cares about complete
serialization of the data model becomes invalid: AIPs or other METs
serializations become incomplete, and thus all the code that relies on them
does too: probably ItemImport/Export/Update need work, and likewise SWORD, OAI
Harvest and the like. I would shoulder such a burden if I thought that this was
a significant architectural extension, but I think it's a lot closer to
administrative metadata that there is a legitimate desire to expose to
end-users.
Therefore, I have definitely charted a light-weight, pragmatic course here: if
one does not want to use the feature, there is absolutely no change to the
system at all - no new metadata registry elements, nor any new Item columns,
etc. If one does, then only for specific items are single, deletable fields
added. If we wish, we could revisit this look to build alternate solutions
easily. I felt based on DCAT's analysis, that it was better to offer something
for 1.8, even if modest in scope.
MarkW rightly distinguishes the state vs transition data, and this reminds me
that DSpace was originally equipped with a 'history' system to record exactly
this sort of information: we pulled it because implementation flaws made the
record unusable - but the idea retains considerable merit, and could contribute
to the rethink he proposes.
> Add optional reason text to tombstone page
> ------------------------------------------
>
> Key: DS-996
> URL: https://jira.duraspace.org/browse/DS-996
> Project: DSpace
> Issue Type: Improvement
> Components: JSPUI
> Affects Versions: 1.8.0
> Reporter: Richard Rodgers
> Assignee: Richard Rodgers
> Attachments: handle-servlet.patch, msgs.patch, tombstone.patch
>
>
> Following the work at UMich (DS-587), this patch will cause the value of any
> configured item metadata field on the withdrawn item's tombstone page to
> display.
> It is configured by the optional property
> 'webui.tombstone.reason=<metadatafield>' in dspace.cfg
> If configuration property is not defined, the tombstone will appear without a
> reason display area.
> If a given item lacks a value for configured metadata field, the reason
> displayed will be the value of the message: 'jsp.tombstone.noreason'
> The prompt before the reason text is the value of the message:
> 'jsp.tombstone.reason'
> Patches below
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
