[
http://jira.dspace.org/jira/browse/DS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10445#action_10445
]
Mark Diggory commented on DS-266:
---------------------------------
Hi,
The following are some thoughts I have on this topic.
Beyond the recurrent issue with provenance, this has been the assumption that
all descriptive metadataa be exposed within DSpace. DSpace evolved as a
rudimentary "Open Access" platform without any capabilities for "embargo" prior
to recent activities to introduce it.
I needs to be clarified how this should be attained architecturally, its
important to understand that the metadata record for a DSpace Item probably
should have never contained sensitive information such as the submitter of the
item, this is detail that should have been retained in the whatever would be
the "history" system for DSpace, now currently absent in 1.5.0 and greater and
attempted as an addon to DSpace by MIT, but without a release and problems with
its implementation, it is actually very important that we see this project
completed sometime in the near future for DSpace.
With out a clear best practice for how to deal with issues such as "sensitive
history/provenance" we have seen repeated adjustments to the dspace interface
code to compensate for data exposure. Hacks to hide specific content, usually
by adding "Yet Another Configuration Option" to the dspace.cfg and hardcoding
logic into the webapplications to introduce "exceptions to the architecture".
Without architectural leadership in regards to how such data should be managed,
stored, accessed, etc, we are doomed to retrace the cycle over and over in
DSpace.
I am hoping to present on some of the architectural vision behind proper
management of additional data storage and the creation of services appropriate
for the storage and retrieval of such data at the October DSUG meeting in
Sweden. Suffice it to say that there should be a separate persistence of this
data outside that of the Item's public descriptive metadata table in teh
database, (even if just a database table) and exposure of this data via a
service in dspace that is access controlled and limited to those with the
appropriate administrators/managers requiring permissions to see it. Provenance
about who has edited or submitted an item to DSpace should be stored explicitly
within a provenance tracking history system, not tacked onto a public
descriptive metadata record.
This is a dramatically different approach to arriving at a solution than
placing exceptions into the webapplication and UI's to hide this detail from
unauthorized users. Its recognizing that the architecture needs to be created
to properly manage "silos" of data that need to be managed separately within
the system.
This also reminds me of the position I had heard mentioned by Rob Tansely in
the past, that for DSpace, the AIP portion of the OAIS best practices is
preserved in an number of different persistence areas of the DSpace storage
architecture, IMO, there is good reason for doing this when it comes to being
able manage, update and control the access to such data. OAIS IP (Information
Package) guidelines seem to be often badly interpreted literally as "we should
package all this information together in the same storage system" to assure its
preservation, IMO the whole system, Database, Assetstore and Whatever other
storage you may employ represents portions of the AIP, and its important that
we recognize where in the environment it is appropriate to be storing specific
details such as change history.
Sincerely,
Mark
> Configure metadata fields to hide in full item display and OAI-PMH harvesting
> -----------------------------------------------------------------------------
>
> Key: DS-266
> URL: http://jira.dspace.org/jira/browse/DS-266
> Project: DSpace 1.x
> Issue Type: New Feature
> Affects Versions: 1.5.0, 1.5.1, 1.5.2
> Reporter: Stuart Lewis
> Priority: Minor
>
> Configure metadata fields to hide in full item display and OAI-PMH harvesting
> Be able to configure a list of fields that should be hidden from public view.
> The cases where these will be shown are full item display, and OAI-PMH, both
> of which show all metadata fields by default (except
> dc.description.provenance).\
> Reported on behalf of Alexander Roberts (Swansea University).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
