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:
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).
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 |
---|---|---|---|
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 |
| ||
Library search strategy |
|
|
|
Staffing |
|
|
|
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