2019-03-06 DSpace Midway Check-in

Date

Feb 7, 2019

Participants

  • @Gabe Galson@Cynthia Schwarz (Unlicensed) @David Lacy @Chin U. Kim @Chad Nelson (Unlicensed) @Annie Johnson (Unlicensed) @Holly Tomren @Christina Harlow (Unlicensed)

Meeting Goals

Let’s decide on, or at least discuss, the following four agenda items:

  1. A UI approach. Should we...

A) Customize and build out DSpace extensively (see DukeSpace)

B) Skin DSpace with a Blacklight interface that will function as a standalone repository and be populated with items pulled from DSpace via OAI (see Columbia's IR).

C) Leave the DSpace UI as-is, or minimally customize it using a theme

D) Just harvesting, no public presence

2. A timeline. What will we release and when, given staffing and technical constraints? The target date is June, but given our UI approach and staffing available will that be doable?

3. A Library Search strategy. I'm assuming we want IR items indexed in library search but I'd like to confirm. We should consider this when setting a timeline.

4. Staffing. Whether we go with A, B or C, integrating IR materials into library search will require developer support. Most of this work will be blacklight-side however. UI-wise, Chin and I alone can execute option C by June, but we'd have to skip many customizations and features requested by Annie/the IR Services group. UI options A and B would take a good deal of additional developer support, while Option C could also benefit from a bit. For example, integrating ORCID into the UI would require developer support, as would many other features.

Discussion topics

Topic

Options

Notes

Decisions

Topic

Options

Notes

Decisions

UI approach

A) Customize and build out DSpace (see DukeSpace)

B) Skin DSpace with a Blacklight interface that will function as a standalone repository and be populated with items pulled from DSpace via OAI (see Columbia's IR).

C) Leave the DSpace UI as-is, or minimally customize it using a theme

 

 

Timeline

  1. Option C in June

  2. Option C in June + A or B by end of year

  3. Option A or B by end of year





Library search strategy

  1. Dependent on Emily and dev’s workload

 

 

Staffing

  1. Option C requires no dev support,

  2. Option C would, however, benefit from dev support. Any feature request from the Services and Metadata group marked ‘Chad/Devs’ in the ‘configuration and enhancements’ section of this doc would require dev support to implement. Many key features, like intergration of ORCIDs into the UI, would require dev support.

  3. Options A and B require dev support.

 

 

 

Notes

Overview of system for Chad and Christina

Concerns about ongoing maintenance of elements… it's a challenge for whoever is assigned this task

Annie- Elements as a deposit platform may not be available to faculty

The primary users and readers of IR materials are not going to TU faculty or students; they’re not going to discover it via library search.

The persistence of the identifiers is important

Cynthia, on timeline

June we could launch with something more minimal, but this is too soon for a blacklight skin (fall? December?)

Annie’s concerns about launching mid summer: 1) No faculty, not a lot of student work is in scope. 2) Shouldn’t our repository look as nice as our website and new building? Why launch with something that doesn’t look good? Why not just take as long as we need?

Chad agrees that we should take more time to develop something that fits the stylistic theme of everything else we’re launching.

Holly’s take… the materials we’re presenting are available elsewhere, so why migrate them into an interface that’s not ready… it needs to be somewhere to put them into the catalog.

David- having a custom front end for a repo is not unique to this group. We have other interfaces born out of other systems (digitized content in CDM, journals in OJS). This supports option B.

Our strategic goal is to be the producer and publisher of things, not just an aggregator. Let’s think about the IR in this wider context.

What already exists? Spotlight?[blacklight add on that allows better curation and customization] Christina can advise the group on it, however don’t confuse it with a repo. bc of spotlights limitations DSpace would still be needed as an admin interface.

 

Chad is leaning towords a single Spotlight codebase for all of our projects (Oral history site, dspace, etc…). This nice part about this setup is that sub-repos can be customized. Christina worked on the blacklight based Columbia IR… implementation was local, and not simple

Chin- customizing DSpace w/ Gabe has been a hacky and time consuming process. Taking it further will require a dev to evaluate it systemically.

Annie- the IR should be an effective marketing tool for itself. Features like ORCID are important to researchers, and are what the Services group.

Cornell has Blacklight on top of DSpace according to Christina

Action item:

Spruce up product requirements matrix

Prioritize enhancements through Services and Metadata group

Bring the prioritized list to Chad and Christina, who will assign each function to a sytem (DSpace back end or ? front end) and advise on implementability. Also maintainability and who would be available to do the work.

Chad and holly agree, the library search question has to be answered after we decide on a UI approach.

Timeline:

Deadline for getting the list- ASAP

Deadline for reviewing the list- ASAP

Action: Create list ASAP and then prioritize with metadata and services groups next week.

Action: Send list to Christina and Chad as soon as it’s ready. Resend when the groups have prioritized items.

Tentative project timeline: Implement option C by June. Chad and Christina will consult on the other options, which could be started in parallel to the work aiming towards option C. The Metadata and Services groups will Integration into library search will happen after a longer-term library plan has been put in place.

 

 

Action items