Product requirements

Standard repository features- front end

Searching, Facets, thumbnails, search results interface, item interface, customizable header footer and landing page

Devs

or

Gabe/Chin

S

M

S: Must have 

M: Must have

Blacklight/DSpace custom

Procedure: https://wiki.duraspace.org/pages/viewpage.action?pageId=30218817

Documentation:  https://wiki.duraspace.org/display/DSDOC6x/Submission+User+Interface

Input forms customized via: https://github.com/DSpace/dspace-release/blob/master/config/input-forms.xml (The form-map maps collection handles to forms.)

Item submission process customized via this:  https://github.com/DSpace/DSpace/blob/master/dspace/config/item-submission.xml  (The process-map maps collection handles to a particular Item Submission Process.)

slide deck: https://www.slideshare.net/bramluyten/secrets-of-the-dspace-submission-form

https://wiki.duraspace.org/display/DSDOC6x/Authentication+Plugins

Devs

Gabe/Chin

'Making DSpace your own' webinar

https://www.slideshare.net/DuraSpace/42418-making-dspace-your-own-webinar-recording

Here's the custom code from the webinar

https://github.com/DSpace-Labs/DSpace-rel-demo

Devs

Gabe/Chin

Devs

Gabe/Chin

Documentation: 

https://wiki.duraspace.org/display/DSDOC6x/DSpace+Google+Analytics+Statistics

RAMP:

http://ramp.montana.edu/

Yes it's implementable.

The Services group must decide on the URL

Devs

ORCID integration- front end

Devs

Cambridge: https://www.repository.cam.ac.uk/handle/1810/266430

Duke: https://dukespace.lib.duke.edu/dspace/handle/10161/8875

DSpace orcid documentation: https://wiki.duraspace.org/display/DSDOC6x/ORCID+Integration

Thread on v6.2 compatibility and 6.3 errors

https://groups.google.com/forum/#!topic/dspace-tech/N_azMfWalD8

GG's orcid doc: https://docs.google.com/document/d/1ump6tlTrd62nvDoXo4I9GBsSdLs5SeY7k1flP2InYTs/edit

6.3 errors doc: 

https://groups.google.com/forum/#!searchin/dspace-tech/orcid|sort:date/dspace-tech/09qKMO-qTyM/lMAKDz04AAAJ

https://groups.google.com/forum/#!searchin/dspace-tech/orcid|sort:date/dspace-tech/N_azMfWalD8/Kzhwner5GQAJ

This is doable through the tweaking of the native theme or another theme like Mirage2.  I was unable to find a way to do this other than through the theme

Note that this could be done easily by adding another language field specifically for display, however the metadata group would prefer to avoid this

Thread on the topic: 

http://dspace.2283337.n4.nabble.com/A-way-to-alter-metadata-values-for-display-td4689929.html#a4689930

Thread: https://groups.google.com/forum/#!searchin/dspace-tech/orcid|sort:date/dspace-tech/f_BZETZYXiM/mavRYst_AwAJ

Auto-Generate MIME types

See convo with Andrea Schweer

Notes from Services Metadata meeting:  This will impact how cumbersome the workflow is for the IR manager.  How cumbersome will depend on the volume of submissions, which is currently unknown.  

Gabe/Chin/Holly

Possibly Devs

DSpace METS SIP Profile: https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile

Extend embargo functionality 

It can easily be enabled in the submission form.  To auto-apply embargos via imported ProQuest metadata we need to provide an exact lift date.  Two additional back-end fields must be implemented, embargo.field.terms and embargo.field.lift.  

Note that there may be an exact date in the regular metadata from proquest ETD admin

Embargo documentation https://wiki.duraspace.org/display/DSDOC6x/DSpace+6.x+Documentation

Implement a variation on this for 'six month', '1 year', etc.: http://wiki.lib.sun.ac.za/index.php?title=SUNScholar/Embargo_Systems/1.8.X

Embargo setter javascript: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/embargo/DefaultEmbargoSetter.java

Should be straightforward

Note:  The Services group's ORCID enhancement depends on this.  

https://wiki.duraspace.org/display/DSDOC6x/ORCID+Integration

Meeting Example:  https://atmire.com/preview/browse?type=title

See note on this page, specifically 'Enabling and building the DSpace 5 Mirage 2 theme' for troubleshooting ideas

Thread on error encountered by Chin, with Fix by Tim Donohue

Gabe/Chin

Maybe devs

S

M

Thread on the issue: 

https://groups.google.com/forum/#!topic/dspace-tech/EQUlVrif-u8

The old DIM2DataCite.xsl crosswalk: https://github.com/DSpace/DSpace/blob/master/dspace/config/crosswalks/DIM2DataCite.xsl

Patched DIM2DataCite.xsl crosswalk: https://github.com/DSpace/DSpace/pull/2321/commits 

Make a backup plan and implement first.  

Use Meld to find versions of our file

M

S

Note: DSpace 7.0 will be released mid 2019

https://www.youtube.com/watch?v=JBH0A3QwBUk . (see 18:36 for directories to back up... back up a) sql and solr databases.  see 20:30, section on using meld to discover differences.  23:50 for folders to check for changes)

• Enable the Repository Tools 2 connection,
• Transmit items in both directions

The systems are integrated and communicating 

This task is complete in Dev.

Configuration can be ported to Prod once the two systems' configurations are OKed by IR Services group

DSPAC-38 - Getting issue details... STATUS

DSPAC-39 - Getting issue details... STATUS

DOIs 

• Create a DSpace DOI generation workflow

• Create a ProQuest→DSpace ingest workflow
• Migrate CONTENTdm ETDs to DSpace

DSPAC-6 - Getting issue details... STATUS

DSPAC-42 - Getting issue details... STATUS

• DSpace's structures should imitate Elements structures, be scalable

DSPAC-45 - Getting issue details... STATUS

DSPAC-46 - Getting issue details... STATUS

• Define DSpace→Elements and Elements→DSpace crosswalks 
• Configure DSpace's fields

• Generate XML crosswalk files

Budget

Determine:

• Storage Budget
• DOI Budget
• Other costs

DOI agency integrated with DSpace

DSpace, when configured so that DOI generation is integrated, automatically generates a DOI for each item added to the repository.  

1. Would this be acceptable?   

2. If not, how would generating DOIs manually look, workflow-wise?

3. How would we deal with the fact that many articles deposited via our RIM already have DOIs?  The DOIs generated in DSpace would have to be manually deleted, and we'd have to get DOIs imported through Elements into the same field as DOIs generated by DSpace.

How would manual generation of DOIs through a new Libraries CrossRef membership work?  This would be the simplest solution, however would require more manual intervention per-item.  

1. Would be a cataloger task?

2. Would this happen through a process integrated into the metadata approval process?  

Subscribing to a DOI Registration agency

1. Crossref -which is difficult to integrate with DSpace and may require dev support for DSpace integration- is cheap ($275 yearly, $1 per DOI).  

2. DataCite -which integrates easily with DSpace- is, annecdotally at least, far more expensive (7k yearly?!?);  Their pricing is opaque, we’d have to get a quote.

DSPAC-37 - Getting issue details... STATUS

DSPAC-41 - Getting issue details... STATUS

1. It’s a complicated question… look at the Australian National Data Services guidelines

   1. Would we have to follow something like this?  

1. ANDS guide

2. Decision tree

• Current CDM metadata should be vetted
• Unless we're porting over all the metadata in CDM, a CDM→DSpace crosswalk must be created

ETD workflow

It's a complicated process!

Do we know of any institutions that have successfully completed a ProQuest→DSpace direct deposit workflow using SWORDv2?

Two options: 

• Flat structure with metadata as access point
• Communities/collections-based structure

• The XML map's limitations mean that items cannot be deposited into collections based on their author's departmental affiliation
• DSpace collections and communities are difficult to restructure after the fact.  Moving collections between collections and communities is also inadvisable.  How then to deal with Temple's constantly shifting administrative structure?  
• Even with no communities or collections custom front end can easily be created by linking to canned searches created by searching specific metadata fields.  
• Department can also be featured as a facet
• Communities and collections facilitate more intricate role definition 

DSpace's Community/Collection structure- Granular

One possible structure- one collection each for 

• ETDs
• Publications
• Data

• Should it be per college?  Per department?  Etc.
• The metadata we can get from Elements limit the granularity of this. 

This involves both

• Metadata work
• Policy Decisions

https://wiki.duraspace.org/display/DSDOC6x/Submission+User+Interface

See the 'Assigning a custom Submission Process to a Collection' section

DSpace's embargo functionality is enabled

Through the ProQuest→DSpace ingest workflow ProQuest's embargo codes can efficiently be translated into DSpace embargoes.  

We'll have to decide if we want to implement DSpace's simple embargo settings or advanced embargo settings.   

The Simple settings can be easily enabled globally.  

We'll need to determine whether we can use the DSpace's 'Creating Embargoes via Metadata' as a part of our Elements→DSpace or ProQuest→DSpace work

Q: Are there any items imported from Elements that will need to be embargoed?  

Guidance text- we'll need to provide a statement

Institutional Advice- we'll need to provide a statement

DSpace- licenses

Customize license for Elements→DSpace submission workflow

a deposit embedded in the Elements interface, usable by both library staff and faculty users of our RIMS 

It must be enabled universally.  Is this a problem?  

This functionality cannot be limited only to certain classes of user.  

The crosswalk allows us to move items deposited from Elements→DSpace to specific dspace collections based on their 'publication type' status in elements.  This could be one solution.  

Library mediated deposits from Elements→DSpace

We've discussed having the library deposit from Elements to DSpace on faculty member's behalf.  

One complication is that Elements indexes articles hosted in other systems, but does not ingest copies of articles.  What are the workflow and legal implications of downloading these articles directly from the publication.

Another complication is that many journals allow the deposit of the preprint or accepted version, but not the publisher's version.  How would we obtain one of the permissible versions, which would be unpublished.  

Is this worth it?  

Is this too far in the wrong direction re: open access?

Elements mapping

Decide which metadata to maintain when migrating from CDM

Create migration crosswalk

Define which fields will be included

Determine how this will fit into workflow

https://wiki.duraspace.org/display/DSDOC6x/Submission+User+Interface

See the 'Assigning a custom Submission Process to a Collection' section

If needed, incorporate 'creating embargoes via metadata' procedures into Elements→DSpace and/or ProQuest→DSpace crosswalks

Blacklight 

WorldCat

And more!  

Decide- do we need them?

If so, how should they be implemented

Newer, incomplete: https://wiki.duraspace.org/display/DSPACE/Authority+Control+of+Metadata+Values

Older, more complete: https://wiki.duraspace.org/display/DSPACE/Authority+Control+of+Metadata+Values#AuthorityControlofMetadataValues-XMLUI

Account for them in the schema

Insert them via the load process

Format: 

|Temple University|College of Science and Technology|Department of Physics

Parse by separator 

Find out: 

1. How much DSpace storage space is currently available?
2. What type of server is this storage on? 
3. How easily can the amount of storage be increased?
4. What are the yearly costs associated with the current level of storage. How much would scaling up cost?

ADA concerns- System

Storage Budget