...
C) Leave the DSpace UI as-is, or minimally customize it using a theme
D) Harvest the UI 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?
...
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
It would be better to
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: No faculty, not a lot of student work is in scope.
Shouldn’t our repository look as nice as our website and new building? Why launch with something that doesn’t look good.
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.
David asks
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… 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