You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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 Edinburgh

Tim Donohue - DuraSpace

Valorie Hollister - DuraSpace

 

 

 

Discussion Notes:

Intro - Valorie Hollister

  • Purpose of call is to bring people up to speed on future of DSpace discussions
  • Three calls with Sponsors -- several of you were participants
  • Will share a summary on the feedback we received so far
  • Jonathan Markow will first start with an overview of recent thoughts around DSpace Futures & Fedora Futures
  • Val will then talk about DuraSpace sponsor feedback
  • Will then open up the floor for feedback from all of you, discussion, questions/comments

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
      • UI is currently difficult to customize
    • 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 needs to have a "repository abstraction layer" - e.g. REST module (GSoC project) - give the ability to use any UIs (i.e. Drupal, Ruby on Rails based, etc) or more easily "hook up" other things to Dspace

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
    • Elin also mentioned an interest but not at top of list
  • Stuart: preservation important - DSpace has "hooks", but not not hanging anything off the hooks in DSpace.
    • e.g. there is a bitstream registry, but don't really use it, no reporting mechanism, need to extend that support
    • Also would be nice to hook into DROID / JHOVE / PRONOM
  • 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 for example to run migration jobs, 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?
    • Worries about the extent at which we seem to ask DSpace to do everything.  Modularity may be the key.
  • Jim: functionality doesn't have to be native to DSpace - like APIs - digital objects can be stored and preserved - 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
    • Dspace should "preserve and provide access to the stuff that people want to put in there"
  • Bram: have sponsors mentioned interest in leveraging repositories as source for out-metrics (altmetrics?) and more advance statistics? Not specifically.
  • Statistics discussion
    • Amy: looking forward to elastic search based statistics in 3.0
    • Tim: elastic search is just a different backend to stats (vs. SOLR), not additional reporting
    • Stuart: 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 scalability issues, but doesn't solve all of what we need
    • Elana: stats are important - our needs are different than normal IR - but helps to justify our existence
    • Elin: stats are a basic need, so folks may forget to bring it up. 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
      • Points out that Google Analytics cannot show stats just for a specific Collection/Community – it's more a tool for site-wide stats
      • DSpace 3.0 adds internal stats for search queries & workflow events
      • Maybe there's a way to use both Google Analytics & internal stats?
  • 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 splitting them?
    • We tend to do everything in one interface for Dspace.  We may see scalability advantages if we split up the access (user) interface from the administrative interface.
  • Tim: mentions the talk of a "repository abstraction layer" (REST API) - 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 DSpace into Hydra (similar to how REST is used to plug Fedora into Hydra)
  • Stuart: makes more sense to build Hydra on top of DSpace - or Islandora on top of DSpace - keep DSpace workflows, but allow for new interfaces on top of DSpace
    • This is more of "Hydra on DSpace" rather than "DSpace on Hydra"
  • Tim: this idea (Hydra on DSpace) could let you tailor interfaces towards diff types of content - sounds plausible, not sure if it is possible - step 1 would be to make sure DSpace has a repository abstraction layer (REST API)
  • Tim: we actually have a few REST API "in the works".  There was the original that was built as a GSofC project - had some scalability problems and access issue (everything open) - several project forks in Github:
  • 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 financial 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 
    • Jonathan points out that on the Fedora side, most of the new Fedora project development is actually being done by existing committers (their institutions were willing to commit extra time to do this extra work on Fedora)
  • 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

 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.