Attendees:
Amy Lana - University of Missouri
Bram Luyten - @mire
Ciarán Walsh - Enovation Solutions, Ltd
Elena Feinstein - University of North Carolina at Chapel Hill
Elin Stangeland - Cambridge University Library
Jim Ottaviani - University of Michigan
Jonathan Markow - DuraSpace
Maureen Walsh - The Ohio State University
Sarah Shreeves - University of Illinois at Urbana-Champaign
Stuart Lewis - University of Edingburgh
Tim Donohue - DuraSpace
Valorie Hollister - DuraSpace
Discussion Notes:
Overview of DSpace and Fedora Futures - Jonathan Markow
- began talking with DSpace and Fedora communities about future of the platforms - because of feedback we've gotten from users - would like improvements to now 10 year old software
- had some discussion at OR - generated some ideas for how to get more energy into the open source development process
- because current pool of volunteer committers only have time to make incremental improvements in software, may want to consider another way of getting more ambitious/bigger projects done
- Fedora community has identified a need to make major changes to Fedora and interested institutions have pooled together resources to spin up a project and get it going
- sense is that the DSpace project has more diversity of needs among users - many users are satisfied with DSpace, but others who want to push the envelope around research data mgmt, digital collections - willing to trade easier out of the box version for more complex one
- just completed a series of calls with DSpace sponsor
DuraSpace Sponsor feedback so far - Valorie Hollister
- What Sponsors LIKE about DSpace:
- meets needs for an institutional repository
- allows for open access to content
- useful workflows
- lots of excitement about features coming in 3.0 and features available in 1.8
- What are some of the CHALLENGES Sponsors face
- digital preservation - some hooks in DSpace for digital preservation, but functionality to serve as a preservation tool has a ways to go
- front end / tools for Admins / UI improvements - customization needs to be easier and more flexible/modern (i.e., customize by collection) and more accessible for Admins
- multimedia needs - multimedia streaming / downloading video/images/audio files
- digital asset mgmt strategy - several institutions are in the middle of a review of their overall strategy, particularly as it relates to research data management
- data management - many institutions mentioned the need to store data and present it in different ways, also the ability to get data in and out of DSpace easily
- author identity / author profile - need to allow content to be showcased in different forms (i.e. BibApp, VIVO) - don't want to re-create metadata or content
- backend improvements - a few institutions mentioned the need for a unified backend
- open/closed content - a few institutions mentioned a need for more flexibility in dealing with open / closed content in order to deal with copyright issues
- What are Sponsors INTERESTED in:
- DSpace/Hydra - a lot of curiosity and interest in the potential of creating a DSpace Hydra head, Univ of Hull has a IR Hydra head, several institutions would like to have one solution for all content (student/faculty, digital collections, data, etc.), some concern about re-creating the DSpace workflows - critical that DSpace maintain its core functionality
- DSpace/Islandora - a few institutions interested in Islandora - which is a Drupal frontend with a Fedora backend, some believe it might be easier / more accessible to customize Drupal than Hydra and that Drupal would provide more flexibiilty for displaying digital assets
- DSpace to be an abstraction layer - REST module (GSoC project) - give the ability to use any UIs (i.e. Drupal, Java-based)
Discussion/feedback from DCAT/Committers - ALL
- Bram: any comment/feedback on RDF/linked data? No, it didn't come up in the most recent discussions
- Amy: we would be interested, but not at top of our list - preservation, streaming would come first
- Stuart: preservation important - not hanging anything off the hooks in DSpace - there is a bitstream registry, but don't really use it, no reporting mechanism, need to extend that support
- Elin: preservation important - need to be to do things like identify files at risk, have the ability to export them out to something like DuraCloud and then easily import it back – linked back to original metadata
- Stuart: need to ask what we see the direction of DSpace? preservation, great interface, streaming, RDF imagining - is it possible to do everything? or should it be something modular?
- Jim: functionality doesn't have to be native to DSpace - like APIs - digital objects can be stored and preserve - but just clicking on a button to download might not be enough - need it to preserve and provide access to whatever people want to put in - I am selling DSpace as a place to put data at our institution
- Bram: have sponsors mentioned interest in leveraging repositories as source for out-metrics and more advance statistics? Not specifically.
- Amy: looking forward to elastic search in 3.0
- Tim: elastic search is just a different backend to stats (vs. SOLR), not additional reporting, aggregating stats might help store more data, but we need to work out what are the reqmts for statistics
- Sarah: interested in Google Analytics - stats is a pain point for us
- Maureen: stats are important - using elastic search because of scaliablity issues, but doesn't solve all of what we need
- Alana: stats are important - our needs are different than normal IR - but helps to justify our existence
- Elin: stats are a basic need - Cambridge hasn't been getting statistics we need - looking for Google Analytics plugin to help
- Bram: Google Analytics vs. existing stats in DSpace - tough tracking downloads - could be opportunities to registered w/Google Analytics, need to think about how stats could be used in the future
- Maureen: scalability is a challenge - we moved to elastic search because of scalability - being able to handle the scale and have functions operate properly - basic performance issues, java error codes - not sure what the problem is - whether it is scale or something else - repository has 50,000 items and 100,000 files
- Stuart: do we need to look at general architecture changes when it comes to scalability - do we split end user functionality / admin functionality - a lot of checks in DSpace - is there a scalability advantage in spliting them?
- Tim: repository abstraction layer - does that allow us to do what Stuart is talking about - create a read-only interface and a separate admin interface to manage content - could you use REST to plug into Fedora?
- Stuart: makes more sense to build Hydra on top of DSpace - or Islandora on top of DSpace - keep workflows - might make more sense to duplicate
- Tim: taylor interfaces towards diff types of content - sounds plausable, not sure if it is possible - step 1 would be to make sure DSpace has a reposibory abstraction layer
- Tim: have a REST API that was built as a GSofC project - had some scalability problems and access issue (everything open) - several project forks in Github - 2 diff forks 1) HDTEK, 2) WIJITI - have resrouce gap to analyze/review code - if one is better than the other, if they can be merged together
- Jonathan: managed projects idea - in the Fedora community institutions interested in getting the work done have started a project - agree on set of features that are critical to improving Fedora now, project participants have committed in-kind donations of dev time (mostly more time from current Fedora committers) as well as finanical support of tech lead and project manager
- Jonathan: for DSpace we hear a lot of diff interests and ideas - if more ambitious ideas are going to take place, it will have to similar to Fedora, would like to hear from anyone who has specific projects that you would like to help with
Next Steps - Valorie, Jonathan, Tim
- Have one more DCAT/Committer call next Wednesday
- will summarize / make transparent what the feedback has been from all mtgs / discussions - likely posted onto the wiki and distributed via the mailing lists
- not sure what projects will come out of discussion - need to determine who has common interests
- want to include everyone who's interested in those projects
- DSpace community has to get the momentum - need more developer time / resources to work on projects - either new developers or more time from existing developers
- DCAT's role will be similar to other development in DSpace - provide feedback on features, make recommendations based on different institutional perspectives
- Committers will help project answer questions and review code submissions
