[
https://jira.duraspace.org/browse/DS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22111#comment-22111
]
Mark Diggory commented on DS-996:
---------------------------------
I draw my position from Domain Driven Design, where one works to encode the
state clearly in the Data Model. Also where Data Model changes are not
considered heavy weight but proper explicit definition of the system one is
building. The challenge with the approach being taken here (and likewise in
Embargo as well) is the the policies expressed are still hardcoded in the
application layer rather than captured in the Domain model itself.
State Vs Transition Data: Yes what we are currently doing with provenance is
transition data and while I dislike the lack of a proper store for that data,
we have to live with capturing the transition in provenance for the time being,
given it is the only place we now have for this. However, the presentation of a
"reason" for withdrawing the Item is "state data" in that when the withdrawn
item is in force it describes the state in more detail. (In fact, this sort of
state data could be used in combination with delete as well, removing the
metadatavalues, bundles, bitstreams, but leaving behind the item record with a
state=deleted and a reason for that deletion would allow OAI PMH removes to be
properly supported for all Items in DSpace, not just those withdrawn. But that
is an aside.)
Concerning the points about changing all the crosswalks packagers, application,
etc, the current dialog clearly misses that we do not want this withdrawn
status exposed to the enduser in the UI, so adding it to the metadata still
requires that we make sure that crosswalks, packagers and User Interfaces are
always properly blocking the exposure of this metadata field and/or any feature
of the Item that may be accidentally exposed in the UI. Is restricting access
to the Item in the UI sufficient? As we recently see, the metadata can still be
gotten from /metadata/handle/... URI. And finally, as Tim points out, we need
to remove the metadata field or protect it from exposure if the item is ever
restored to the repository. What we see here is a cheap quick solution and
then having to write exception cases into the application in all places the
data may be exposed. What I propose is to add it to the data model and only
expose it in the cases where it is needed. So its a matter of perspective, one
mans "lots of extra work" is another mans "much less work". The data is only
exposed where it is needed.
Please note Withdrawn items are not an edge case because there is a lower
percentage of them in a repository in relation to archived items. The feature
is an important 80/20 rule for Repository Requirements. It is a feature used in
less than 20% of Items but is utilized by greater than 80% of the users. It is
a feature we've observed being used in every DSpace instance we've seen
deployed.
I thought quite awhile about this design dialog and my conclusion is the
following. For enduser customizations where your organization may make a
change to the behavior of the application and want to still be free to upgrade
DSpace without maintaining local changes to the database schema, usage of the
metadatavalue table may be sensible until we achieve a better approach for
storing Object System properties. However, for long term changes to DSpace
that are committed to the official distribution, we should not be comfortable
with this approach. We should be striving to achieve solutions that do not
promote "Procrusteanism". With this in mind I am still against storing the a
reason for the withdraw in the metadata in the form shown in both issues. I
would prefer to see it stored in the Item table where it can be stored without
creating further convoluted conditional metadata filtering rules in all the
applications. This doesn't mean you wouldn't record it in the
dc.description.provenance as a transition record, this would/could still be the
case. But that the reason itself should be system metadata.
The appropriate direction of design is to (1) add the field to the table, (2)
create some simple setters/getters on the Item, (3) add a form field to the
withdraw view so that the value can be added to the item.
I think its critical we make the best possible design choices when designing
the core data model and features of DSpace. This was one of the reasons for
creating the formal Domain Model, so we can design explicit capabilities and
features of DSpace via the Domain itself, not by creating vague metadata
mappings of state and hardcoding their meaning and logic in the surface
application instead of in the core data model.
I am tempted to express a vote of -1 on DS-996 and DS-587 until we see some
agreement here, we should be working to get the design right now, not making
compromises and putting off proper design choices later.
> 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
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
