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
- Twin goals of DSpace: preservation & access to research & scholarship
- 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"
- Institution #1 - Lots of integration points & access - less about preservation
Overview
Content Tools