Versions Compared

Old Version 5

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 6

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: spelling corrections

...

Stuart Lewis - University of EdingburghEdinburgh

Tim Donohue - DuraSpace

Valorie Hollister - DuraSpace

...

  • 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 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 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
    • 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 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
    • AlanaElana: 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 spliting 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 plausableplausible, 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 finanical 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

...