Page History

...

• Do we need two platforms? DSpace & Fedora
  
  • Need to see if the 3-5 yr "visions" overlap for the platforms. Think of as a venn diagram - may be a lot of overlap or little
  • Would be important to the University Librarians - need a message as to why give to one or both. Show that we've analyzed whether merging platforms is worthwhile
• Types of DSpace institutions
  
  • Institutions who are essentially happy with DSpace as out-of-the-box IR
  • Institutions who are stretching the boundaries of DSpace
    
    • Faculty wanting something easier to use, "flashier".  Even building their own tools, using other (non-preservation) system
  • "In between"  - like the simplicity but want "flashier" interface, similar
• Is there a common vision for DSpace? (even amongst our small group)
  
  • In many ways it has morphed from it's initial use case that is was built for
  • Should it be a generic digital repository, or concentrate on solving just IR / preservation repository?
• Institutional Visions / Use Cases
  
  • Institution #1 - Lots of integration points & access - less about preservation
    
    • DSpace is free, relatively robust.  Large User community.
    • End user deposit. published & unpublished content
    • Managing diverse research output (ORCIDs).  Data with access controls. Digital Collection & Mgmt)
    • Research info mgmt systems.  Needs good integration points
    • Integrates into a different digital preservation.
    • Streaming server, stats module were added as they went
    • "Killer App" = E-Theses.  Harder stuff is images/video.
  • Institution #2 - Started small and simple, constantly expanding
    
    • Initial decision was it is open source. Philosophy to support OS
    • Capturing university output
    • Getting to streaming servers
    • "In between group" - like ease of use. Small library - students used to do input
    • Migration of some content from ContentDM to DSpace.  Having requests to extend DSpace to add some ContentDM features
    • Feeding publications (university publishing) direct to DSpace
    • Getting data in and out easily
    • Went with Islandora for a Digital Library solution (better "Digital library" product than DSpace).
      
      • Question has come up whether to use Islandora instead of DSpace for some content
      • Possibility: Using DSpace as a true "preservation repository" and feeding content to Islandora (or similar)
    • Positives outweigh the negatives at this point.  But, how many systems can they really support amongst digital library / IR services?
  • "DSpace with a lot of 'hooks' on it" - could solve a lot of use cases with good integration points. But, shifts focus of spending staff time integrating and supporting a larger suite of software. - Tito
  • Institution #3
    
    • At time of adoption (early on), unique & filled a necessary role. Capturing the scholarship in a repository (initial needs came from library community)
    • Main concerns are performance issues / scalability
    • Handling preservation mgmt
    • Continued modularization of DSpace - lots of things people want, but do we keep adding into DSpace.
    • DSpace not a swiss army knife. 
    • Lack of flexibility for non-text formats
    • Handle issues - cannot move content around easily as you cannot "split" a Handle prefix
  • Institution #4
    
    • Important that it is OS and successful with textual formats.  Good submission workflows.
    • Built up a lot of local expertise with DSpace
    • DSpace as sole Digital content mgmt system
    • Lots of user demand for images & data. DSpace not designed for these materials
    • Need for stronger preservation support. 
    • More complex metadata
    • Moving in a more modular direction.  Want DSpace to fit well into that ecosystem (modular instead of "stand alone")
  • Not the staffing to support Fedora.  DSpace is "perfect fit" in that it's turnkey, etc.
  • Institution #5
    
    • DSpace provides Persistent long term access.  Easily findable items
    • Want a system that can meet multiple types of needs.  Not enough staff to support many systems
    • DSpace is part of preservation strategy (and DuraCloud and other tools)
    • Need for stronger preservation support
    • Need to better support special collection
    • Journal article metadata becoming more critical. As is data
    • Want it to also "work well with" streaming server solutions (for video / audio). Better integration
  • Institution #6
    
    • At the time, it was the "out-of-the-box" product
    • Place to put documents for easy access.
    • Using both for archival materials and scholarly content
      
      • Future to make it look "partitioned" to search types of content separately 
    • Integration with things like Symplectic Elements and/or VIVO.  Pull in metadata from external sources (easier deposit)
    • Data becoming more critical.  Both open access data, and data only for local community
    • Managing research data (long tail data...small data)
    • Hard to get stuff out of DSpace once it is in there (e.g. move it elsewhere).  Handle issues (cannot split up handle prefix)
    • Willing to run different systems for different purposes. But, limited staff – so needs to be easier integrations. Simplicity important
  • Institution #7
    
    • Role: mature IR platform, but has not evolved to solve all the various other use cases beyond narrow IR institutions
    • Imagine DSpace as an IR "backbone". Enforces various use cases for IR needs.  But interoperate with other tools/services that can solve other use cases
      
      • Interoperability with Tools:  e.g. DSpace more friendly with existing tools that solve preservation problems / dissemination, etc.
      • Interoperability with Services:  Large user community, which could be leveraged to build an 'ecosystem' of services which are "DSpace-aware".
        
        • Framework for modules/plugins , which would allow institutions/service providers to integrate other services into DSpace.  Could be supported by DuraSpace
    • Don't want to build more & more functionality on top of a monolith.  Want to create an "adapter" to plugin to other services & tools.
    • Some examples: Discovery & Access
      
      • E.g. specialized interfaces for searching across ETDs.  Perhaps ways to link that up to printing ETDs.
      • E.g. distributed digital preservation
    • Why use DSpace instead of something else
      
      • sunk costs - costs to switch
      • not a lot of digital content solutions that meet the base IR needs
  • Institution #8
    
    • Twin goals of DSpace: preservation & access to research & scholarship
      
      • content has to be related to research / scholarship.  Other types of content go in other systems
    • Worked well for that purpose.  Works well with textual docs.
    • Now getting some images / research data sets.  Small sized to medium sized data sets, DSpace works well
    • Limitations in terms of preservation side of things
      
      • investing in Fedora as a preservation platform (for all content, not just IR)
    • DSpace will be more of an ingest/access system.  Preservation will be in a separate platform "underneath"
    • Need to move content easily in/out of DSpace because of that
    • Increasing value.  Use ability to delegate control of Collections & Communities to departments to do their own training/submissions. Easy for people to pick up and use in that way
    • Have a large amount of "sunk costs".  Would like to see platform/community move
    • DSpace should continue to provide base IR functionality.  But, expand to handle more complex environment (e.g. relationships between sets of items).
    • DSpace should either improve with Preservation or have easier hooks to other preservation tools/services
    • Easier hooks into research profiler system or similar
  • Institution #9
    
    • DSpace is about Preservation, visibility & access to your work
    • Dspace great at end user deposit, creation of collections.
    • Do virtually zero vetting of what goes into DSpace.  Trust faculty to make this decision
    • "Directors cut" - multiple things under one handle
    • Good that you can put anything in it.  Can be a preservation problem
    • Preservation tools could be improved.
    • Like open source nature.
    • Want to look at handling small or large data sets in DSpace
      
      • hard to get stuff "out" (especially large data sets)
    • Concerns about the monolithic nature of code.  Need: "set of legos"
• Pain Points / Frustrations
  
  • Poor end user experience
  • Customizations are "hard". Plugging things in. Code modifications (monolithic)
    
    • Hard to maintain once you make customizations.  Upgrades become more painful.
  • Current Content Model - especially difficulty with relationships
    
    • metadata per bitstream  (e.g. preservation or admin metadata)
      
      • different types of files all related, but requiring their own unique metadata
    • hierarchical metadata
    • relationships between items
    • Needs a more flexible content model in general (hierarchical content model)
      
      • for preservation use cases, you might want to organize in on way.  for access, perhaps another way
      • Communities, Collections & Items hierarchy do not work for all use cases
        
        • inflexibility of this model causes you to have to work around it or "hack it"
  • No native support for complex metadata
    
    • Research data metadata is hard
  • Lack of training possibilities
    
    • Lack of user documentation for DSpace
  • Cost of ownership. Making installation/configuration/upgrades easier
  • DSpace primary UI technology based on aging technology (Cocoon)
  • Ease of use of getting data in/out of DSpace (metadata, actual content, etc.)
    
    • Getting data out in a form that is "useful" to researchers (for data mining, etc)
    • Also statistics lost if you move data out and back in
  • Scaling concerns. 
    
    • Concurrency issues (tuning for large scale concurrent access)
    • Scaling issues related to Collection size
  • Getting content in/out
    
    • Delivery of large files out of DSpace
    • Also getting large files into DSpace
    • Improved support for Bulk Uploads into DSpace (not to have to send to your programmer)
  • Governance & getting things (fixes / features) into the codebase.  Not enough developer resources.
  • Model to share common tools into a "commons" that are "DSpace aware". Lack of a framework to share these tools & manage.