Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 could be 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.