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.

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

Compare with Current View Page History

« Previous Version 17 Next »

DSpace 3-5 Year Vision and High Level Roadmap Meeting - May 9 & 10, 2013

Logistics

  • Meeting Location: UIC Campus, Richard J Daley Library, Room 1-470 (Floor 1, Room 470)
    • Walking directions from Crowne Plaza Hotel to Richard J Daley Library (801 S Morgan St): http://goo.gl/3uZOX
      • Daley Library is located mid-way between Harrison and Taylor streets.  It has a large west entrance on Morgan Street.
    • You can also take the #8 Halsted bus (runs every 10mins or so) for $2.25 (they accept dollar bills & quarters). See CTA schedule: http://www.transitchicago.com/riding_cta/busroute.aspx?RouteId=167
    • If you are coming direct from an airport, the "UIC Halsted" stop on the CTA Blue Line train is the best option. From there, you can follow the walking directions and continue south on Halsted (~5 minute walk)
      • From O'Hare airport, just take the Blue Line directly to the UIC Halsted stop (No transferring).  From there, you can follow the walking directions and continue south on Halsted (~5 minute walk)
      • From Midway airport, take the Orange Line to downtown Chicago.  Transfer (for free) to the Blue Line at the "Clark & Lake" stop (descend two flights of stairs from elevated tracks to subway).  Take the Blue line towards Forest Park. Get off at the UIC Halsted stop. From there, you can follow the walking directions and continue south on Halsted (~5 minute walk)
  • Meals
    • Lunch & Dinner on Thurs will be provided for all attendees
    • Breakfast on Fri will also be provided

Attendees

  • Jonathan Markow, DuraSpace
  • Tim Donohue, DuraSpace
  • Allan Bell, U of British Columbia
  • Sandy De Groote, University of Illinois at Chicago
  • Doug Goans, Georgia Tech
  • Sue Kunda, Oregon State
  • Amy Lana, University of Missouri
  • Jim Ottaviani, University of Michigan
  • Sarah Potvin, Texas A&M
  • Monica Rivero, Rice University
  • Robert Sandusky, University of Illinois at Chicago
  • Sarah Shreeves, University of Illinois (at Urbana-Champaign)
  • Tito Sierra, MIT
  • Maureen Walsh, Ohio State University

Preparatory Reading

Contributions from Others

Agenda

Day 1: Thursday, May 9, 2013, 12:00PM – 5:00PM

  1. Lunch (12-1 PM)
  2. Introductions
  3. Expected Outcomes.
    1. What do we hope to achieve by the end of these planning sessions?
    2. What happens next?
  4. Sidebar.
    1. Diversity in the DSpace community
  5. Vision and Product Placement.
    1. What is unique about DSpace?
    2. What important niche does it fill for you?
    3. What about it provides value to your institution?
    4. What is your vision for DSpace over the next five years?
  6. Pain Points.
    1. What has been most frustrating about the use of DSpace at your institution?
    2. What characteristics of DSpace stand in the way of fulfilling your vision for the product?
  7. Brainstorm: Use Cases and Associated Features.
    1. What Use Cases are important for your institution over the next five years?
    2. What are the associated features that need to be supported?
    3. What kind of content needs to be supported?

Dinner out – 6:30 PM

Day 2: Friday, May 10, 2013, 8:30AM – 12:30PM

  1. Light breakfast (8:30AM – 9:00AM)
  2. Prep work on Vision Statement / High Level Roadmap
  3. Prioritize Use Cases
  4. Plan Next Steps
    1. Volunteer assignments

 

 

Notes

  • 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.
  • No labels

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