Submission improvements: document type-based submission
-------------------------------------------------------

                 Key: DS-1127
                 URL: https://jira.duraspace.org/browse/DS-1127
             Project: DSpace
          Issue Type: Improvement
          Components: DSpace API, XMLUI
    Affects Versions: 1.8.1, 1.8.0, 1.8.2
            Reporter: Nestor Oviedo
            Priority: Major
         Attachments: type-based-submission-classes.zip, 
type-based-submission-diff-files.zip

Document type-based submission

As outlined in 
https://wiki.duraspace.org/display/DSPACE/Document+Type+Based+Submission, many 
repositories deal with several document types and the only approach DSpace has 
to offer so far is a collection based form definition.
We found the following initiatives: https://jira.duraspace.org/browse/DS-464 
and https://wiki.duraspace.org/display/DSPACE/Document+Type+Based+Submission , 
but they are very old and it is very hard to integrate one of them in our 1.8.0 
DSpace. Along with this problematic integration we also need some other 
features to the submission process, which made the integration yet more 
complicated.
These initiatives propose to define a type-based form and/or pages, but we 
thought this would lead to a very complicated and redundant form definition, 
provided most document types share a lot of common fields. To avoid this 
replication, we propose to have a type-based field definition in the form 
configuration (input-forms.xml). That is, defining the forms and pages fields 
in the normal way, and only specify a type-restriction on those fields which 
are specific for some kind of document.

The following excerpt is an example o a form definition:
<form name="traditional">
        <page number="1">
                <field>
                        <dc-schema>dc</dc-schema>
                        <dc-element>type</dc-element>
                        <label>Document type</label>
                        <!-- other field properties -->
                </field>
                <!-- many others common metadata, like author, title, some 
date, language, etc -->
        </page>
        
        <page number="2">
                <!-- many others common metadata, like abstract, subjects, 
identifiers, etc -->

                <!-- Here we have a field specific for a theses -->
                <field>
                        <dc-schema>theses</dc-schema>
                        <dc-element>director</dc-element>
                        <label>Thesis director</label>
                        <type-bind>theses</type-bind>
                </field>

                <!-- many others common metadata, like coverage, some 
institution name, some other date, embargo info, etc -->
        </page>
</form>

The visibility of the type-based field depends on the dc.type field's value. 
This requires the dc.type metadata must be fullfilled before the rendering of 
any page with any type-based field.

This approach allows you to mix fields, even though they are restricted to a 
document type. Also, you can define multiple document types in the <type-bind> 
element, separated with a colon (,). i.e 

                <field>
                        <dc-schema>dc</dc-schema>
                        <dc-element>identifier.isbn</dc-element>
                        <label>ISBN</label>
                        <type-bind>theses,ebook</type-bind>
                </field>

Other improvements

Considering we have now a type-based submission, we need to be able to define 
the same field for different document types, with different attributes. A clear 
example of this in our repository is the ISBN metadata: theses may have an ISBN 
metadata while books must have it. Also, the label and hint of these fields 
could be different. To achieve this we avoided the limitation on field 
duplicity, allowing to define the same field multiple times.
Another minor improvement proposed here was previously mentioned by Claudia 
Jürgen in https://jira.duraspace.org/browse/DS-334. We agree with Claudia in 
that the visibility and the required attribute are not related directly, so we 
removed that validation. We consider that the mandatory restriction makes sense 
only when the field is visible in a scope. Thus it is completely valid to 
define a visibility scope along with a required attribute.

Attachments

Here you can find two attachments: a zip containing the modified classes, and 
another zip containing the diff for all the modified classes (this diff was 
made against the 1.8.0 version).
We attached diff files for you to have a quick overview of the changes made.

--
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

       

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to