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)
all - discussion / feedback / question
Discussion
-any feedback on RDF/linked data? didn't come up
--Amy would be intereseted, but not at top at list
--preservation, streaming would come first
-preservation
Stuart Lewis - not hanging anything off the hooks - bitstream registry, but don't really use it, no reporting mechanism, need to extend that support - interrogate
Elin - identify files at risk and ability to export out (DuraCloud?) - easily import it back, link back to metadata
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? should we provide
Jim: functionality doesn't have to be native to DSpace - like APIs - digital objects can be stored and preserve - click on a button that can download might not be enough - need it to preserve and provide access to whatever people want to put in
Bram: have sponsors mentioned interest in leveraging repo as source for out-metrics - more advance statistics?
Amy: hoping for elastic search in 3.0 - it is easier SOLR or elastic search - just a different backend to stats, not additional reporting, agreggating stats might help store more data, but we need to work out what are the reqmts for statistics
Sarah: intested in Google Analytics - stats is a pain point for us
Maureen: stats are important point - using elastic becasue 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
Maureen/Elin: it is 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: scalbility - moved to elastice search because of scalability - being about 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 - repo has 50,000 items and 100,000 files
Stuart: general arch - when it comes to scability - 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 seperate admin interface to manage conttent - could you use REST to plug into Fedora?
STuart: make 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 scalibiltiy 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?
-Fedora - people 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 as well as finanical support of tech lead and project manager
-DSpace - 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
DCAT ROLE
-not really sure what projects are there - need to determine common interest
-want to include everyone interested in the process involved, that's why we having the calls
-DCAT help promote projects - give feedback
-Committers - help review code
-community has to run with it - we can help - Fedora Futures is a good example - grass roots movement, invited us to take part - but it came from them - how could something similar happen in DSpace
-transparent discussion summaries
