Page History

Preparing for the call

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

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)