[
https://jira.duraspace.org/browse/DS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19017#action_19017
]
Mark Diggory edited comment on DS-164 at 2/16/11 7:35 PM:
----------------------------------------------------------
Having participated in GSOC as a mentor for this project. I can comment that
what the student created for inputforms was a functional solution that enabled
support only for the forms. I challenge what we need here though, is an
overall reconsideration of Item Content Modeling and Validation for DSpace
1. Of what value are the input-forms in their current design? We
repeatedly find our team using inputforms as a form of pseudo schema for
validation of user input. I would recommend that we need to separate the
concepts of visualization of input forms from the validation of the assigned
metadata, so that validation can be applied at the time of review and archiving
(possibly a curation task) rather than as a Submission Activity
2. Of what value are the Controlled Vocabularies in their current
form, again we in @mire tend to repurpose these files during import/export to
validate and transform fields from other systems into expected CV values in
DSpace. In recent projects, we have actually replaced the CV and
InputForms with Authority Controls and more specifically, should we work to
deprecate CV's and Value Lists in favor of the AUthority control abstraction?
TBH, we all know these UI that utilize popup windows are rather
antiquated.
DSpace Needs a Validation "Engine" for Items that meets the following Criteria
* Associates Validation Rules with DSpace Item "Content Types" independent of
Submission
* Can be used by InputForms and Submission to define appropriate forms.
* Can be called after Packager and ItemImport tool processing to flag Items
that are in an invalid state.
* We can then associate those Content Types with Collections rather than
InputForms.
* Ideally this is considered part of the DSpace Domain Model and is persisted
into either DB and/or Assetstore as a formal attribute of the Collection
and/Community.
* Ideally this is architected using the DSpace II Services Approach to allow
its implementation to be an independent addon to the dspace core.
* Ideally, this validation engine is content centric rather than collection
centric, an this also pertains to the allowed metadata fields being associated
with the Item Content Model, it would be best to consider it as an extension of
the MetadataRegistry such that the Registry can be customized and made specific
to different Item Types.
was (Author: mdiggory):
Having participated in GSOC as a mentor for this project. I can comment
that what the student created for inputforms was a functional solution that
enabled support only for the forms. I challenge what we need here though,
is an overall reconsideration of Item Content Modeling and Validation for
DSpace
# Of what value are the input-forms in their current design? We
repeatedly find our team using inputforms as a form of pseudo schema for
validation of user input. I would recommend that we need to separate the
concepts of visualization of input forms from the validation of the assigned
metadata, so that validation can be applied at the time of review and archiving
(possibly a curation task) rather than as a Submission Activity
# Of what value are the Controlled Vocabularies in their current
form, again we in @mire tend to repurpose these files during import/export to
validate and transform fields from other systems into expected CV values in
DSpace. In recent projects, we have actually replaced the CV and
InputForms with Authority Controls and more specifically, should we work to
deprecate CV's and Value Lists in favor of the AUthority control abstraction?
TBH, we all know these UI that utilize popup windows are rather
antiquated.
DSpace Needs a Validation "Engine" for Items that meets the following Criteria
* Associates Validation Rules with DSpace Item "Content Types" independent of
Submission
* Can be used by InputForms and Submission to define appropriate forms.
* Can be called after Packager and ItemImport tool processing to flag Items
that are in an invalid state.
* We can then associate those Content Types with Collections rather than
InputForms.
* Ideally this is considered part of the DSpace Domain Model and is persisted
into either DB and/or Assetstore as a formal attribute of the Collection
and/Community.
* Ideally this is architected using the DSpace II Services Approach to allow
its implementation to be an independent addon to the dspace core.
> Deposit Interface
> -----------------
>
> Key: DS-164
> URL: https://jira.duraspace.org/browse/DS-164
> Project: DSpace
> Issue Type: New Feature
> Reporter: Charles Kiplagat
> Priority: Major
>
> Suggestions included: a web interface for altering input-forms.xml, being
> able to select an input form "on the fly" based on the type of item being
> deposited, a web interface to the Configurable Submission System, eliminating
> the need to restart the server after changes to input-forms.xml and the
> Configurable Submission System, allowing more configuration (e.g.
> input-forms.xml, Configurable Submission) and command-line actions (e.g.
> batch imports) to be pushed down to community and collection administrators,
> allowing metadata specific to an eperson (e.g. name, metadata fields to
> exclude) to be stored in that eperson's profile, It was noted that the lack
> of a web interface to many DSpace configuration files means that repository
> managers who are not also systems administrators may not be able to configure
> their installations fully.
--
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
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
