DCAT Meeting December 2017

Background: The Developer Team recently had detailed discussions around where DOIs are stored in DSpace, and how to better manage their storage going forward.
Currently, based on the DOI system instances have configured, DOIs may be stored in "dc.identifier.uri" (alongside Handles), in "dc.identifier", or in "dc.identifier.doi".  See this ticket: https://jira.duraspace.org/browse/DS-2199

After much discussion, the Developer Team proposes, starting with DSpace 7, (automatically*) moving all DSpace-generated DOIs into a new (for DSpace master code) "dc.identifier.doi" field. This would standardize their location, and also keep them separate from Handles (which are stored in "dc.identifier.uri"). The full details of the proposal can be found in this ticket: https://jira.duraspace.org/browse/DS-3708 

The Developer Team notes that the "dc.identifier.doi" field is another non-standard DC field (for the master code). But they would like to simply keep DOIs in a location alongside other identifiers. However, they hope that, in the future, a Metadata Working Group (or similar) could be established to help the Developer Team determine the DSpace metadata best practices going forward.

*it would happen automatically during the upgrade process, and wouldn't be configurable.  But, they would only automate for DOIs that *DSpace generated* (they can determine this based on data in the 'doi' database table).  So, any other DOIs you are storing which are not generated by DSpace would be kept where they currently exist.

Preparing for the call

Please review the DCAT Google Group thread "Proposal to move all DSpace-generated DOIs to dc.identifier.doi" and tickets:

Unable to locate Jira server for this macro. It may be due to Application Link configuration.  

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

In preparation for the call, you could do the following:

• Share any questions you may have
• Think about local institution code implications
• Share how you are using DOIs currently (what systems/plugins you are using, what fields you are using, how you are displaying DOIs, differences for minting versus manually assigned, etc.)

Meeting notes

Maureen Walsh, moderator

Tim Donahue, presenter:

Discussion re: proposal in ticket DS-3708:  Issues where DSpace sites store DOIs.   Stored in different metadata fields depending on the service used:  DC.IDENTIFIER or DC.IDENTIFIER.DOI.  Proposal is to standardize where DOIs generated by DSpace are stored in dc.identifier.doi.

Question:  Many DOIs are coming from outside DSpace, would this affect where those are stored?

Answer:  Up to the institution

Question:  Where are institutions putting DOIs generated from outside DSpace?

Answer:  dc.identifier.doi, dc.identifier.uri

Question:  Could we use a shoulder to indicate which are generated by DSpace?

Answer:  Possibly, if we used a specific shoulder to indicate DSpace-generated DOIs.

Commentary: 

• 
  
  • DSpace-generated only through Datacite
  • Institution didn’t realize that dc.date.available field was used by OAI/PMH harvesting.  Can it be made clear which required fields used by DSpace may be used for other purposes?
  • One institution uses dc.identifier.doi, but manipulating the landing page so that the DOI shows instead of the handle.  Also, anything that looks like a URL = a link.
  • Bioethics library has over 300,000 records; DOIs are placed in dc.identifier.uri
  • Simple item view may show both the DOI and URI/handle
  • Ideal if item view was configurable on an item-by-item basis
  • Suggestion that a report be offered that lists all the DOIs in the repository
  • Some institutions use the handle as part of the DOI
  • Would be nice if we could have categories for Dublin Core metadata fields. 
  • Some institutions create fields to fit new purposes.
  
  Summary of discussion:  Proposal is OK; More configurability in the user interface would be ideal

DSpace 7 update:  Development is slower than expected because of small development team.

All the updates/notes are on the wiki page:  DSpace 7 Working Group . 

Atmire and 4Science are developing, some Texas A&M on Angular, IUPUI helping on some:

Live demo sites: 

Demo DSpace 7 UI: https://dspace7-demo.atmire.com/

Demo DSpace 7 REST API: https://dspace7.4science.it/dspace-spring-rest/

Demo of basic browse and search functionality.  Not heavily themed, because institutions will be using Bootstrap theming.  Can browse REST API and practice custom requests.

Back side:   Team that is working on enhancing the search functionality, providing more options for sorting/display of search results

Team working on submission process; demo may appear in January.  Mock ups are available on DSpace 7 UI Mockups .  Feedback requested.  Administrative tools yet to come.

Want to have a working demo (early preview release) by Open Repositories next year.

Question:  Work being done on viewers? 

We discussed integrated viewers and DSpace.  Regarding IIIF viewers, assets in DSpace may different from the assets used by a viewer, perhaps as individual pages.   This leads to a loose integration with DSpace..

Call Attendees

• Maureen Walsh (Ohio State University)
• Tim Donohue (DuraSpace)
• Marianne Reed (University of Kansas)
• Pauline Ward (University of Edinburgh)
• Iryna Kuchma (EIFL)
• Terrence W Brady (Georgetown University)
• Anne Lawrence (Virginia Tech)
• Anna Dabrowski (Texas A&M University)