Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Attendees

  • Virginia Tech (Zhiwu Xie)
  • MIT (Richard Rodgers, Sean Thomas)
  • Harvard (Reinhard Engels)
  • U of Cincinnati (Linda Newman, James Vanmill)
  • DuraSpace (Tim Donohue, Jonathan Markow, Valorie Hollister)
  • Ohio State U (Maureen Walsh, Bill, Beth Warner, Kira Cornell, Peter Dietz)
  • U of Delaware (Mark Grabowski)
  • Indiana U (Jon Dunn, Randall Floyd)
  • Stanford (Tom Cramer)
  • Cornell (Dean Kraft, Simeon Warner)
  • U of Hull (Chris Awre)
  • DCE - Data Curation Experts (Mark Busey)
  • Cambridge (Jon Norm)

Notes:

  • Overview of DSpace Futures (Jonathan)
    • Initial meetings back in fall (Oct / Nov)
    • These are followups.  We identified three main topics of interest from those initial meetings
      • REST API
      • Hydra + DSpace
      • Metadata Improvements
    • Now trying to see if we can coordinate ideas/projects around any of these topics
  • Hydra + DSpace discussion so far
    • Two main brainstorms of how this could happen..both still a bit fuzzy
    • "DSpace on Hydra" - A Hydra Head that looks/acts similar to DSpace.  This would essentially be DSpace "rebuilt" as a Hydra Head in Ruby on Rails, with a Fedora Backend
    • "Hydra on DSpace" - Hydra Framework on a DSpace backend.  Existing or Future Hydra Heads could potentially run on DSpace instead of Fedora.  Hydra would communicate with DSpace via a REST API, likely, just like Fedora.
  • Tom Cramer
    • Either of those approaches likely mean building some sort of "DSpace-like" head/interface on hydra.
    • Two existing Hydra heads which have some overlap with DSpace functionality.  Either of these could be a good starting point for a "DSpace-like" interface on Hydra.
      • Sufia / ScholarSphere (out of Penn State)
      • Hydrous (out of Stanford) - includes a 2 stage workflow
  • Reinhard: Where is the DSpace in "DSpace on Hydra". It sounds like you'd just be recreating it all in Hydra / Ruby.

    • Jonathan - conceptual structure / workflow that are inherent to DSpace. Possible to duplicate much of this in Ruby on Rails. Make it look like DSpace but have a different underneath.

  • Dean - Cornell

    • Currently run DSpace, but are trying to move more things over onto Hydra. Want DSpace but in a Hydra Framework, cause they are moving other applications to Hydra stack. Want a Fedora backend, but a "DSpace-like" front end

    • Interested in keeping the DSpace feel on top of Fedora

  • Jonathan - what about other Dspace users? how do you feel about this?
  • Zhiwu  - Virginia Tech

    • Our users don't necessarily like the front end of DSpace. They like the DSpace concepts though.  But, the UIs need some cleanup / work (too many clicks, hard to deposit)

    • Hydra on DSpace.  Would it be a service to the community to have the Hydra Framework support multiple backends (DSpace and Fedora)?  It wouldn't matter what you are using underneath Hydra.

  • Linda at Cincinnati

    • Hydra on DSpace is attractive. But, is DSpace really flexible enough to support it?  Or are DSpace & Fedora just too different

    • repository that is UI agnositic is attractive - community and collection structure is useful, but don't have an alternative way to find items 

  • Jon at Indiana
    • Running DSpace & Fedora. More work now with Hydra. Would like to converge on a Fedora backend, and likely a Hydra frontend
    • lots of things are users like about DSpace, DSpace Hydra head that is easier to customize and improve is attractive - having it run on DSpace backend is less attractive
  • Richard @ MIT:
    • worth investigating functional clone of Dspace on Hydra
    • but I was more intersted in a more flexible UI - for many institutions the simplicity of the DSpace stack/backend that is attractive
    • Wants the simplicity of the DSpace architecture, with the more flexible UI of Hydra.
    • Jonathan: Does it require the backend to be DSpace? Or could it be Fedora that "looks like DSpace".
      • Richard: Good question
    • Tom Cramer: Has heard some similar thoughts amongst Hydra folks as Richard.  They like Hydra's flexibility but have been unsure about Fedora pain points / complexity. Many use Fedora as an opaque datastore - big application server
      • Fedora Futures: Make Fedora easier to run / scalable.  Hydra would eventually run on this Fedora 4 platform.
  • Chris at Hull:
    • Fedora can be a complex beast.  Developer now works entirely thorugh Hydra and avoids touching Fedora.
    • They are a smaller institution that needs simplicity (like DSpace). But they were concerned that too much simplicity could be limiting over the longer term (would the simple scale into the future?)
  • Richard: Yes, this is an important point as to where you want to invest your resources. Sees value of "backend consolidation".  But, could also be a unification around common Skills/Technologies (e.g. Ruby on Rails) across different backends.
  • Reinhard
    • How much of the Fedora API does Hydra rely on?
      • Tom: only uses the REST APIs of Fedora (small subset of Fedora API).  Hydra stack uses two main ruby gems for Fedora: ActiveFedora, and OM.  OM maps the models to ActiveFedora, and ActiveFedora makes calls to Fedora.
    • Could we reproduce this in DSpace REST API?. (Tom: Conceptually, yes, but devil may be in the details.)
    • (Someone else) notes that another option would be to create two new ruby gems for DSpace interaction (ActiveDSpace, etc.), rather than trying to get the DSpace REST API "look like" the Fedora REST API.
  • Mark Busey (DCE) gives an example of something else under Hydra
    • San Diego has their own "DAM" they developed in house.  Wanted Hydra on frontend.  UCSD & others decided to try and put Hydra on their DAM.
      • Wrote an interface abstraction layer to build an API that translated Fedora API calls to DAM API.
  • Reinhard: Going with Hydra on DSpace would coincide with the REST API needs for DSpace. May be same/similar project.
  • Richard: Bare in mind that Fedora's data model is much more flexible than DSpaces.  Might be a challenge?
  • Simeon Warner: Most interested in the functional replacement for DSpace in Hydra.  Obviously that's considerable work though.
  • Would it be possible to replicating this subset of Fedora API (used by Hydra) in DSpace REST API?
  • Linda:
    • Need to understand how Hydra calls the Fedora stack
    • Need to talk to UCSD folks about how they tried to hook their "DAM" into Hydra.  May help inform DSpace work
  • Peter Dietz (OSU)
    • Could someone sell me on Hydra?  Why go with Hydra on top of DSpace instead of just building a new Ruby on Rails app on DSpace (via REST API)
    • Mark Busey: Lots to take advantage of in Hydra world. Page turners, streaming media, complex objects, etc. - already people in community who have thought through them – Hydra is both technical and commuity Not needing to do everything from scratch. Can lean on others in the community – solve problems together. 
    • Tim seconds this: collaborative opportunitiy to work with Hydra community and improve on what has already been developed. The big question though is whether you can plug Hydra into a DSpace REST API – hopefully it's possible.
  • No labels

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